Can DDS protocol be used to communicate between devices connected to different networks?How? - data-distribution-service

Question

I am trying to implement a publish and subscribe hello world program for communication between 2 devices using eclipse cyclone DDS protocol, I am able to do it when devices are connected in the same network but when devices are in a different network there is no communication happening. As per my understanding, it's because of the default DDS domain but how do I change it?
I followed https://github.com/eclipse-cyclonedds/cyclonedds
Here there's a mention to make use of an XML file, but I am not understanding how to use it or where to use the file.
Any suggestion would be of much help, thank you!

Answer 1

Cyclone DDS looks at the value of the CYCLONEDDS_URI environment variable to find its configuration file. What you can do is make an XML file somewhere on your computer and put its path in that environment variable. E.g., on Linux:
export CYCLONEDDS_URI=/path/to/cdds.xml
or on Windows (“cmd”, I don’t know how to do it in powershell):
set "CYCLONEDDS_URI=c:/path/to/cdds.xml"
Windows is a bit tricky with the quotes, this seems to work fine. Then, when you start your application, Cyclone DDS will read that file and apply the settings in it. Of course you also need to know what to put in it.
For that, it is useful to know a few things about the networks you are using. In one network, it all works without any configuration because the UDP/IP multicast works semi-magically in a single network. If there are multiple networks, there is a router in between and those routers are often configured not to route multicast traffic.
That means you basically have two options:
Configure the routers to route multicast traffic between the networks (especially the 239.255.0.1 address used by default by DDS). If that works, you’re all set, no need to configure anything in Cyclone DDS.
Disable the use of multicast and instead list the hostnames/IP addresses of the machines you want to communicate with in the configuration file. You still need a router willing to route traffic from the one network to the other, but that is usually not a problem with unicast packets. (If for example you can ping it or login to it remotely, it’s fine.)
For (2), something like:
<CycloneDDS>
<Domain>
<General>
<AllowMulticast>false</AllowMulticast>
</General>
<Discovery>
<ParticipantIndex>auto</ParticipantIndex>
<Peers>
<Peer Address="ip-of-node-1" />
<Peer Address="ip-of-node-2" />
<Peer Address="ip-of-node-3" />
/Peers>
</Discovery>
</Domain>
</CycloneDDS>
should work (obviously with the ip-of-node-1 &c. replaced with the correct addresses/hostnames). Setting “AllowMulticast” to false simply disables all use of multicast. If multicast doesn’t work reliably with all nodes, assuming it works can give a broken system. So at this stage, it is definitely easier to just not use it.
The “ParticipantIndex” has to do with the UDP port numbers it uses. With multicast, multiple processes on a single machine can all use the same UDP port number for receiving the discovery packets, and so there is this agreed-upon port number for discovery that makes everything work without any configuration (port number 7400 for domain id 0). That in turn allows it to use random port numbers for receiving unicast traffic.
With unicast, however, each process needs to have its own unique port number, and that in turn means the other processes need to know to which port numbers to send the data to. Setting the “ParticipantIndex” to auto forces it use predictable port numbers so that the processes can find each other.