add ZMQ interface

[LorenzoFerriniCodes]

Hi, thanks for the cool project!

I've been recently working on implementing the ZMQ interface, via zmqpp. Here is a first, working version. I have tested it both locally and over an office network, succesfully. You can test it using the dedicated configuration files. I will add README information about it over the next days. Feedbacks are absolutely welcome :)

[brow1633]

Sweet! Readme would be great, and would also appreciate adding a ZMQ test (similar to TCP/UDP tests) to run with CI.

I'll make some time to take a look. Thanks!

[LorenzoFerriniCodes]

Hi @brow1633, thanks for the quick response! I have included the tests (which are passing locally) and a dedicated demo launch file. I have also updated the README.

[brow1633]

'ament_target_dependencies' is deprecated, please use 'target_link_libraries' instead. Looks like CI has become more flaky, I'll make another PR at some point to address. Otherwise looks good!

[brow1633]

Just curious, do you have a use case for Push/Pull specifically? I think this adds something potentially useful in that multiple pushers can go to one puller (many robots to 1 monitor). Or 1 command center to many available worker robots.

However, this does not seem to handle the case of one publisher to many subscribers (1+ robot/s to 1+ monitors).

Would it be easy to add configurable Pub/Sub to support this behavior with a configurable topic name?

I think it might be worth adding some of these considerations to the selecting a protocol section of README.

This adds some really cool functionality! Thank you!

[LorenzoFerriniCodes]

I agree with you that probably PUSH/PULL is not the best default setup given the round robin polling behaviour. I can see multiple nodes subscribing, for instance, to the camera stream. In this case the PUSH/PULL behaviour does not meet the ROS requirements in terms of message delivery.

I think that in some cases, where developers are sure there's going to be a 1-to-1 publishing/subscription behaviour, still having the PUSH/PULL pattern available can be useful. However, PUB/SUB should be the default one.

I was thinking to define a pattern parameter (default value pub_sub) to define the type of message exchange pattern. What do you think about it?

[brow1633]

Yeah, I think that makes sense!

…

On Thu, Apr 23, 2026 at 1:48 AM Lorenzo ***@***.***> wrote: *LorenzoFerriniCodes* left a comment (brow1633/network_bridge#19) <#19?email_source=notifications&email_token=AXLCDG4VXH5KKJVUM4H2FRD4XHKGPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMZQGMYDEMBZGU32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJNLQOJPWG33NNVSW45C7N5YGK3S7MNWGSY3L#issuecomment-4303020957> I agree with you that probably PUSH/PULL is not the best default setup given the round robin polling behaviour. I can see multiple nodes subscribing, for instance, to the camera stream. In this case the PUSH/PULL behaviour does not meet the ROS requirements in terms of message delivery. I think that in some cases, where developers are sure there's going to be a 1-to-1 publishing/subscription behaviour, still having the PUSH/PULL pattern available can be useful. However, PUB/SUB should be the default one. I was thinking to define a pattern parameter (default value pub_sub) to define the type of message exchange pattern. What do you think about it? — Reply to this email directly, view it on GitHub <#19?email_source=notifications&email_token=AXLCDG4VXH5KKJVUM4H2FRD4XHKGPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMZQGMYDEMBZGU32M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJNLQOJPWG33NNVSW45C7N5YGK3S7MNWGSY3L#issuecomment-4303020957>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXLCDG5DTEEDIVFLXNM6JWL4XHKGPAVCNFSM6AAAAACX5CU45KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGMBTGAZDAOJVG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[LorenzoFerriniCodes]

Hi @brow1633, sorry for disappearing over the last couple of weeks. I have pushed the changes regarding the pattern for ZMQ message handling. I will try to fix the issue with the deprecation of ament_target_dependencies tomorrow, I am having some troubles building the project locally for kilted.

[LorenzoFerriniCodes]

@brow1633 all the tests are passing locally now. I had to apply to the CMakeLists some changes that might look a bit convoluted; this is due to the fact that zmqpp_vendor has changed its way to expose libraries and headers via variables between jazzy and kilted, most likely due to ament_target_dependencies entering the deprecation stage.

Something I did not mention before: the ZMQ tests are now testing both PUSH/PULL and PUB/SUB patterns.

[brow1633]

Looks great! Only thing I'd ask is to add a bit in README about push/pull vs pub/sub, then looks good to merge!!

Thank you!

[LorenzoFerriniCodes]

@brow1633 I have updated the README. I have separated the information about interface implementation from the rest of the subsection, to improve visibility (it looked a bit like a dangling paragraph after introducing information about the supported ZMQ patterns)

[brow1633]

Seems to be some flakiness with CI. I can try and check later if you don't find anything obvious.