Demystifying DDS

Data Discovery Services (DDS) is a middleware protocol that enables real-time, scalable, and reliable data exchange between applications. I have first encountered it in ROS2 and thought that this might be an upgrade of MQTT where they might have replaced the remote broker with something of their own. Now, as I am trying to take a deeper dive into ROS2, I have found out that DDS is a distributed service. There is no centralized deamon controlling the connections of nodes or anything. So, here is my understanding of DDS and how it works on ROS2.

Lets look at the high-level architecture of MQTT and DDS.

We see that there is no concept of centralized control in DDS. In MQTT, all subscribers and publishers connect to the message broker. But, in DDS, we have DomainParticipants which uses a global Data Bus for communication.

Lets break DDS down. The main components of DDS are:

• DomainParticipant
• DataWriters
• DataReaders
• Publishers
• Subscribers
• Topics
• QoS etc.

At its very core, there is the concept of Domain. A DDS Domain is a seperate communication plane, a logical network. Each Domain has a unique DomainID. The role of DomainID is very significant in DDS.

A DDS Domain, with a specific DomainID, is the logial network of applications. Each Domain has their own logical communication space, the Data Bus.

DomainParticipants with the same DomainID will know about each other and potentially establish communication among them. DDS middleware will ensure that DomainParticipants with different DomainID will never communicate.
Thus, whenever a new DomainParticipant is created, it will advertise its presense in the whole network but only interact within its Domain. Each DomainParticipant will maintain information about the Entities created by itself and also other DomainParticipants in the same Domain.

So, How does DomainParticipants find out about each other?

In DDS, DomainParticipants follow a discovery protocol. Most common protocol is the Simple Discovery Protocol (SDP). It has two phases:

1. Simple Participant Discovery Protocol (SPDP)
2. Simple Endpoint Discovery Protocol (SEDP)

In SPDP Phase, DomainParticipants learn about each other. ParticipantDatas are sent periodically to the devices network. DDS Middleware looks at the ParticipantDatas and make logical networks based on DomainID. This phase uses best-effort communication. Once DomainParticipants know about each other, they move to the SEDP phase.

In SEDP Phase, DDS Middleware matches the DataWriters & DataReaders are matched. PublicationData and SubscriptionData messages are exchanged among DomainParticipants. These exchange of messages continue until each DomainParticipant has a complete database of information about other DataWriters and DatReaders. Then the discovery process is complete and the system switches to a steady state. This phase uses reliable communication. During this steady state, ParticipantData messages are still sent periodically to ensure liveliness of the participant and also to discover new participants.

For each DomainParticipant, there are six objects automatically created for discovery purposes. The top two objects are used to send receive participant DATA messages, which are used in the Participant Discovery phase to find remote DomainParticipants. This phase uses best-effort communications. Once the participants are aware of each other, they move on to the Endpoint Discovery Phase to learn about each other’s DataWriters and DataReaders. This phase uses reliable communications.

While the discovery process is going on, a matching phase starts. In this phase, DataWriters are matched with DataReaders. A match occurs if both the DataWriter and the DataReader have same topic, data-type and compatible QoS Setting. Communication between them starts only when both sides agree to the established connection.

When a DomainParticipant is deleted, it sends a ParticipantData(Delete) message with the DomainParicipant’s details. Other DomainParticipants update their database according to this delete messsage.

DDS in ROS2

Lets make a rough picture of DDS in ROS2. ROS_DOMAIN_ID is the DomainID for the underlying DDS. Each Node in ROS2 creates a DomainParticipant under the hood. DataWriters are Publishers and DataReaders are Subscribers. The discovery process is the same as described above.


Resources:

1. RTI Connext DDS Documentation
2. Whitepaper: An Introduction to DDS and Data-Centric Communications
3. Fast DDS Documenation
4. DDS in a Nutshell