You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The C&DH server is using pyzmq's send_string and recv_string when passing data. This is an artifact of the initial implementation for this being done in Python 2.7.x and then converted over. Some of the updates to handle the format changes from the 3.x cutover are less than ideal, including some eval calls.
Ultimately, most handlers and plugins are expecting to receive a bytes-like object as a default. Some will have expected addition processing so they might expect a more complicated message format (e.g., many of the packet handling plugins expect to receive a tuple of the form (packet id, packet data blob)). We should update the way we are passing data so the default expectation is met.
The current suggested changes are to update all 0MQ pub-sub calls to use either send / recv or send_pyobj / recv_pyobj. The payload will be a pickle-serialized tuple of the form (message topic, bytes-like data object). This should keep topic handling simple and flexible like the current form, avoid unnecessary str <-> bytes conversions, and ensure that the previous data form expectations for handlers and plugins is being met (again). This will require updates in Core and GUI.
The text was updated successfully, but these errors were encountered:
Update server handling of data passing to use 0MQ's
`[send|recv]_multipart` calls instead of `[send|recv]_string`.
Utilities have been added under ait.core.server.utils for encoding /
decoding messages into the proper format to simplify code throughout.
Various hacks for handling the string-ified data have been removed.
Resolve#299
The C&DH server is using
pyzmq
'ssend_string
andrecv_string
when passing data. This is an artifact of the initial implementation for this being done in Python 2.7.x and then converted over. Some of the updates to handle the format changes from the 3.x cutover are less than ideal, including someeval
calls.Ultimately, most handlers and plugins are expecting to receive a bytes-like object as a default. Some will have expected addition processing so they might expect a more complicated message format (e.g., many of the packet handling plugins expect to receive a tuple of the form
(packet id, packet data blob)
). We should update the way we are passing data so the default expectation is met.The current suggested changes are to update all 0MQ pub-sub calls to use either
send / recv
orsend_pyobj / recv_pyobj
. The payload will be a pickle-serialized tuple of the form(message topic, bytes-like data object)
. This should keep topic handling simple and flexible like the current form, avoid unnecessary str <-> bytes conversions, and ensure that the previous data form expectations for handlers and plugins is being met (again). This will require updates in Core and GUI.The text was updated successfully, but these errors were encountered: