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
{{ message }}
Repository navigation
Incompatible interface for zmqhub with official csp when using csp v1 #59
I noticed that when using the CSP version 1 mode with csp init -v1 , CSH does not prepend the data sent through zmq with an extra byte containing the destination address. This make CSH unable to coexist on a zmqhub network with other CSP V nodes using the official libcsp. In my use case it is not an option to switch to v2 as we have equipment locked to v1.
For my setup I can fix it myself but I wanted to now why CSH was behaving differently.
Okay thank you for the feedback. I know there was a bugfix in csp upstream regarding V1 and ZMQ, related to an old endianness problem i believe. I have not seen that the entire byte was missing before, but maybe you can report on the fix and the behaviour of V2 ZMQ, because the addreess space is larger than a byte.
I think the rationale behind that byte in v1 is to do some filtering in the zmq layer, where conditions on the messages start can be set. This is not needed in v2 as dest and src have been switched so zmq can use the first two bytes of the CSP header.
I guess that this byte was forgotten when libCSP went to 2.0 then added later after your fork.
Also conforming to libcsp would not only updating the fork but also applying the fix to your version of zmqproxy.
There might be some endianess shenanigans at play as well . I noticed this when trying tu put CSH, gomspace's csp-client and custom nodes on a zmqhub and the different message sizes was the first issue i noticed.
I think the filtering in ZMQ on ID is done in the pub/sub portion of ZMQ. So its dont already on serverside when registering a subscriber socket, so there is no need to append it to each message. I think the upstream author made a bit of confusion between the filtering method and the endianness.
Well I'm not sure if it is the exat reason they added this byte in the v1 zmq interface... The question is: Is it worth your time making CSH backward compatible with other csp1 nodes?
Activity
johandc commentedon Apr 10, 2026
Okay thank you for the feedback. I know there was a bugfix in csp upstream regarding V1 and ZMQ, related to an old endianness problem i believe. I have not seen that the entire byte was missing before, but maybe you can report on the fix and the behaviour of V2 ZMQ, because the addreess space is larger than a byte.
Quettle commentedon Apr 10, 2026
Hi,
I think the rationale behind that byte in v1 is to do some filtering in the zmq layer, where conditions on the messages start can be set. This is not needed in v2 as dest and src have been switched so zmq can use the first two bytes of the CSP header.
I guess that this byte was forgotten when libCSP went to 2.0 then added later after your fork.
Also conforming to libcsp would not only updating the fork but also applying the fix to your version of zmqproxy.
There might be some endianess shenanigans at play as well . I noticed this when trying tu put CSH, gomspace's csp-client and custom nodes on a zmqhub and the different message sizes was the first issue i noticed.
Quettle commentedon Apr 10, 2026
I found the missing PR libcsp/libcsp#738
johandc commentedon Apr 10, 2026
I think the filtering in ZMQ on ID is done in the pub/sub portion of ZMQ. So its dont already on serverside when registering a subscriber socket, so there is no need to append it to each message. I think the upstream author made a bit of confusion between the filtering method and the endianness.
Quettle commentedon Apr 10, 2026
Well I'm not sure if it is the exat reason they added this byte in the v1 zmq interface... The question is: Is it worth your time making CSH backward compatible with other csp1 nodes?
johandc commentedon Apr 13, 2026
CSH just follows CSP master, so question is, what broke inside CSP and when.
Quettle commentedon Apr 13, 2026
The master branch or your libcsp fork has the fix, but the commit used in CSH doesn't.
johandc commentedon Apr 18, 2026
Okay, so all we need is a fresh csh release, thank you for investigating.