I'm enjoying ROS2 so far, but one major issue is that the UDP broadcasting slams the network when sending things like images/pointclouds. Most of the time I'm running on one machine and don't want packets to even leave that machine. Is there a way other than manually configuring tables to tell a node or set a flag that keeps packets on the machine?
Originally posted by talos on ROS Answers with karma: 25 on 2018-11-04
Post score: 0
Original comments
Comment by William on 2018-11-05:
Which middleware are you using? By default I think most use unicast UDP (so using the ROS_DOMAIN_ID works fine there), but multicast UDP for data is possible too. In which case you might need to adjust the TTL for the multicast addresses being used, so that they do not leave the machine.
Comment by talos on 2018-11-05:
The default EProsima DDS. Maybe I'm incorrect in thinking it was multicast? I only was concerned because our IT guy sent us an email detailing the increase in data over the network from my machine...
How can I adjust the TTL?
Comment by William on 2018-11-05:
Yes, the default is eProsima's Fast-RTPS (not technically a DDS implementation, just the wire protocol). Even if the message data (images/pointclouds) are not being sent over multicast, the discovery information is being sent over multicast.
Comment by William on 2018-11-05:
There isn't a way to just change the TTL for ROS 2 at the moment, I had proposed a way to do this in this issue: https://github.com/ros2/rmw_fastrtps/pull/79 but since Fast-RTPS at the time, and I assume still now, does not use multicast for data, I closed it.
Comment by William on 2018-11-05:
It should be possible to change the TTL in your machine's firewall, though that will prevent discovery as well and perhaps affect other things like discovering network printers, etc. Which OS are you on?
Comment by William on 2018-11-05:
But at this point we're just guessing at why you're traffic is increased, so you might want to have a look at Wireshark and see what's actually getting sent over the network.