How does DDS work?

At its core, DDS operates on a publish-subscribe pattern, but it distinguishes itself through its sophisticated discovery mechanisms, rich Quality of Service (QoS) policies, and a standardized wire protocol known as RTPS (Real-Time Publish-Subscribe).

This section explores the technical underpinnings that enable DDS to deliver robust, real-time communication.

Participant Discovery

DDS systems are dynamic. Devices can join or leave the network at any time. This is handled by the Simple Participant Discovery Protocol (SPDP).

  1. Multicast Announcements: When a DDS application (Participant) starts, it periodically sends presence announcements via multicast.
  2. Automatic Detection: Other Participants on the network listen for these announcements. Once detected, they exchange information to establish a unicast channel.
  3. Plug-and-Play: This process is entirely automatic, requiring no manual configuration of IP addresses or central servers.

Endpoint Discovery & Matching

Once Participants are aware of each other, they share information about their DataWriters (Publishers) and DataReaders (Subscribers) using the Simple Endpoint Discovery Protocol (SEDP).

  • Topic Matching: A DataWriter and DataReader will only match if they communicate on the same Topic and use compatible data types.
  • QoS Compatibility: Beyond topics, the middleware checks if the requested Quality of Service (QoS) by the subscriber is compatible with what the publisher offers. If they are incompatible (e.g., a subscriber demands reliable data from a best-effort publisher), communication is not established, preventing system misbehavior.

Quality of Service (QoS)

The rigorous QoS negotiation is a hallmark of DDS. It allows granular control over data delivery:

  • Reliability: Make communication strictly reliable (with retries and acknowledgments) or best-effort (fire-and-forget for high-speed telemetry).
  • Durability: Determine if late-joining subscribers should receive historical data or only new data.
  • Liveliness: Automatically detect and report if a component fails or stops updating its data within a specified timeframe.
  • History: Control how much data is kept in the cache for retransmission or late-joiners.

Data Serialization

For efficient transmission, DDS uses Common Data Representation (CDR) serialization.

  • Standardized Format: CDR is a standardized binary format defined by the OMG, ensuring interoperability between different DDS implementations and programming languages.
  • Efficiency: It is designed for speed and compactness, minimizing CPU usage and network bandwidth.
  • IDL (Interface Definition Language): Data structures are defined using IDL, which is then compiled into code for the specific language (C++, Rust, Python, etc.), ensuring type safety and optimal serialization code.