add ZMQ interface#19
Conversation
e8dccdf to
f1850fe
Compare
|
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! |
Included information about the ZMQ interface.
|
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. |
|
'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! |
|
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! |
|
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 |
|
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:
***@***.***>
|
- Defined parameter to select the message forwarding/receiving pattern - Adapted socket connection and binding to use the specified pattern
|
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 |
Hi, thanks for the cool project!
I've been recently working on implementing the
ZMQinterface, viazmqpp. 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 :)