networks//middleware//DDS

DDS (Data Distribution Service) is an Object Management Group standard for publish-subscribe middleware, with automatic discovery of participants and configurable quality-of-service policies per data stream, and it is the transport underneath ROS 2 as well as of many defence, industrial and automotive systems. Fast DDS, from the Madrid company eProsima, is the default implementation in several ROS 2 distributions; Cyclone DDS and Zenoh (a different protocol with a ROS 2 binding) are the common alternatives.

DDS (Data Distribution Service) is an Object Management Group standard for publish-subscribe middleware, with automatic discovery of participants and configurable quality-of-service policies per data stream, and it is the transport underneath ROS 2 as well as of many defence, industrial and automotive systems. Fast DDS, from the Madrid company eProsima, is the default implementation in several ROS 2 distributions; Cyclone DDS and Zenoh (a different protocol with a ROS 2 binding) are the common alternatives.

What sets it apart from a plain message bus is quality of service (QoS): each publisher offers, and each subscriber requests, a set of policies, and the middleware honours them. Four matter in practice. Reliability is reliable or best effort: best effort for high-rate sensors, reliable for commands, maps and configuration. History keeps the last NNN samples or all of them: N=1N=1N=1 for control, where only the latest counts. Durability is volatile or transient-local: transient-local so that a node arriving late still receives the last map. Deadline is the maximum period between messages, which turns a sensor that has gone silent into an event.

Best effort with keep-last 1 is the rule send state, not increments turned into configuration (communication constraints). When each message carries the full state, losing one does not matter and retrying it only delivers stale data; messages carrying increments need reliability, and pay its delay.

The reliable transport over lossy links trap: on a lossy Wi-Fi link, reliability means retries and retries mean delay, so a reliable image stream jams exactly when the signal worsens, and the newest image waits behind old ones the receiver no longer wants.

Incompatible QoS fails silently. A publisher offering best effort and a subscriber demanding reliable simply do not connect, and the only trace is a warning in a log: the subscriber sees no data and no error. In ROS 2, ros2 topic info --verbose lists the QoS each endpoint offers or requests, which is where the mismatch shows.

Discovery by multicast is convenient on a lab network and a nuisance on a large or segmented one (traffic grows with the number of participants, and some networks block multicast), which is why deployments configure discovery servers or restrict domains.

DDS runs over UDP on an operating system, so it is not a hard real-time transport; the fast loops stay on a microcontroller or a fieldbus (middleware).