Search code examples
udpmulticastdata-distribution-serviceros2unicast

Is multicasting necessary for DDS based communication?


I have a configuration where 3 applications run on 3 different Virtual Machine's and they must communicate via DDS i.e. RTPS protocol. The configuration is as follows :

  1. ROS2 based ADAS functions
  2. Simulation Tool
  3. Python/Tensorflow based machine learning functions

All 3 need to be on different VMs.

It is not possible at our end to allow multicasting for the MS AZURE VM and our network. Here are some questions :

  1. Is it still possible to communicate via DDS ?
  2. If yes, through UNICAST i.e. peer to peer connection ?
  3. Is using DDS communication beneficial in this case if i already have the option of basic UDP socket programming ?
  4. Could you think of any restrictions/ further problems in using DDS for such a configuration ?

Solution

  • Is it still possible to communicate via DDS ?

    Yes, it is. Out of the box, DDS Participants only use multicast for discovering other DDS Participants, at startup. This discovery mechanism can be configured in several ways. For a an explanation on how to achieve that, see this RTI Community Knowledge Base article: Configure RTI Connext DDS to not use Multicast.

    If yes, through UNICAST i.e. peer to peer connection ?

    Yes, with the no-multicast setup, all communications are done over UDP unicast, peer to peer, connectionless.

    Is using DDS communication beneficial in this case if i already have the option of basic UDP socket programming ?

    Not being able to use multicast does not remove any of the DDS advantages when comparing it to UDP. When using DDS, the transport/discovery configuration is typically invisible to the application and all Publish/Subscribe concepts remain unchanged.

    If you are asking about the advantages of using DDS versus UDP, I think that warrants a new question on itself. The answer will be quite extensive :-)

    Could you think of any restrictions/ further problems in using DDS for such a configuration ?

    With this configuration, your configuration settings will be dependent on the network that you are running on. This means that migration to a different network might need reconfiguration, for example providing different host names or IP addresses. This is inconvenient, but not hard.

    Since your environment is restricting the use of multicast, I would not be surprised if there are more restrictions that you have not mentioned or discovered. For example, do you know anything about firewalls or network bandwidth restrictions? Again, DDS can be configured to deal with such things, but you need to be aware of them first.