Proposal : Restrict DDS to localhost by default

1

Hi,
I would like to make a proposal for rolling / future versions of ROS2:

Restrict DDS (or whatever RMW) to localhost by default.

The reasons for this is pretty simple and straight forward:

  • Currently, it is super easy to interfere with someones else’s stack, without noticing. This has happened to us a lot, and is a real pain to debug.
  • The standard solution of using ROS_DOMAIN_ID doesn’t quite cut it. Especially for bigger networks, you need to have a hand crafted list of taken IDs for every workstation in the network etc.
  • A multi host setup is an advanced setup, therefore we can expect the user to take the burden of configuring it explicit.

Any options on this ?

P.S.: Is there a poll feature in this board somewhere ?

2 Likes
2

We’d basically go back to ROS 1 default behaviour, which I would agree with causes the least surprise for (new) users.

The current multi-machine default combined with the fact node names are not required to be unique can make figuring out “where are these phantom messages coming from?” really “fun”.

As changing defaults will take some time, you could consider setting ROS_AUTOMATIC_DISCOVERY_RANGE to a suitable (default) value for your organisation/environment for now:

https://docs.ros.org/en/rolling/Tutorials/Advanced/Improved-Dynamic-Discovery.html

3

We already configured everything to restrict ROS2 to localhost.
We just found, that the default is sub optimal, and would like the opinion on this
from the rest of the people using ROS2.

4

For what it is worth, we attempted to do this for Iron. We fell short because we couldn’t get all of our tests to pass with localhost only as the default. You can see some of our working on this in Proposed changes to how ROS performs discovery of nodes , and Improve handling of dynamic discovery · Issue #1359 · ros2/ros2 · GitHub and Sloretz/test discovery by sloretz · Pull Request #512 · ros2/system_tests · GitHub .

So in order to get there, someone would need to spend the time to figure out exactly what doesn’t work in which combinations, and then see if it can be fixed. The ROS development core team probably won’t have time for this before Jazzy, since we already have the switch to Ubuntu 24.04 and rmw_zenoh_cpp on our plate.

4 Likes