Revision history [back]

The "domain participant ID" is just a number that allows you to configure a sort of "virtual network" or "virtual overlay" which makes DDS participants that do not use the same number ignore each other, it does not influence the networking component of DDS.

What you are referring to ("only in the same network") is actually due to the fact that in the default configuration many (all?) DDS implementations use (UDP) broadcast traffic for peer discovery.

By default, many routers and gateways are configured to not pass on broadcast traffic and additionally, the DDS implementation may only broadcast to the local subnet (ie: all IPs in the same range).

But that is not an inherent issue with DDS, nor with ROS2. It's a configuration issue (and many DDS implementations support either discovery with a pre-defined list of participants or a unicast discovery, or even both), and even if the specific middleware doesn't support changing it, there are various networking techniques that can be used to bridge two (or more) network segments in such a way that broadcast traffic is allowed to flow between them.

The "domain participant ID" is just a number that allows you to configure a sort of "virtual network" or "virtual overlay" which makes DDS participants that do not use the same number ignore each other, it does not influence the networking component of DDS.DDS. See Part 2: Core Concepts > Working with DDS Domains > DomainParticipants > Choosing a Domain ID and Creating Multiple DDS Domains for the RTI explanation of this.

What you are referring to ("only in the same network") is actually due to the fact that in the default configuration many (all?) DDS implementations use (UDP) broadcast traffic for peer discovery.

By default, many routers and gateways are configured to not pass on broadcast traffic and additionally, the DDS implementation may only broadcast to the local subnet (ie: all IPs in the same range).

But that is not an inherent issue with DDS, nor with ROS2. It's a configuration issue (and many DDS implementations support either discovery with a pre-defined list of participants or a unicast discovery, or even both), and even if the specific middleware doesn't support changing it, there are various networking techniques that can be used to bridge two (or more) network segments in such a way that broadcast traffic is allowed to flow between them.

The "domain participant ID" is just a number that allows you to configure a sort of "virtual network" or "virtual overlay" which makes DDS participants that do not use the same number ignore each other, it does not influence the networking component of DDS. See Part 2: Core Concepts > Working with DDS Domains > DomainParticipants > Choosing a Domain ID and Creating Multiple DDS Domains for the RTI explanation of this.

What you are referring to ("only in the same network") is actually due to the fact that in the default configuration many (all?) DDS implementations use (UDP) broadcast traffic for peer discovery.

By default, many routers and gateways are configured to not pass on broadcast traffic from their own network to other networks they are connected to and additionally, the DDS implementation may only broadcast to the local subnet (ie: all IPs in the same range).

But that is not an inherent issue with DDS, nor with ROS2. It's a configuration issue (and many DDS implementations support either discovery with a pre-defined list of participants or a unicast discovery, or even both), and even if the specific middleware doesn't support changing it, there are various networking techniques that can be used to bridge two (or more) network segments in such a way that broadcast traffic is allowed to flow between them.