Data Distribution Service (short DDS) is a ISO/OSI >= transport layer protocol (UDP, TCP, Serial and custom), developed by the Object Management Group (OMG). Like MQTT, DDS works with the messaging pattern publish-subscribe but not have a central component like the broker MQTT use.
The programming is quite easy, we just have Writer and Reader to a so called Global Data Space.
Writer example:
import cdds
...
topic = dds.Topic("Vehicle", "Speed")
dw = dds.Writer( topic )
dw.write( ... )
...Reader example:
import adds
...
topic = dds.Topic("Vehicle", "Speed")
dr = dds.Reader( topic )
...The Global Data Space (Short GDS), represented by each distributed node, having a local cache on Data Object’s (short DO).
Note: Each node has its own GDS. The GDS is nothing on physical network layer.
These DO have (more or less) unique address build from a topic name and a key name, making DDS a so called data– and not service-centric protocol. All together, the local stores give applications the illusion of having access to the entire Global Data Space and makes it up too hard real time (ready).
Each application locally stores only what it needs and only for as long as it needs it, configured via Quality of Service (short QoS) attributes:
- Data availability
- Durability as how long data lives in the GDS
- Lifespan as interval of time the data is valid in the GDS
- History as the number of DO samples in the GDS
- Data delivery
- Presentation for managing data coherency
- Reliability as reliable vs. best effort or often in other terms TCP vs. UDP
- Partition for data segregation and traffic control e.g., routing or content centric networks (short CCN) – usually by the DO keys
- Ownership as rights on topics
- Data timelines as constraints for inter GDS sync
- Deadline as maximum time of arrival – not the time sync is mandatory
- Latency Budget as a kind of overall time budget for publisher and subscriber tasks
- Transport Priority as non time based priority
- Resources
- Time Based Filter as the maximum update rate (n times per millisecond) of the GDS
- Resource Limits the maximum storage size of the GDS
Logical model of DDS
Note: The (hard) realtime variant of DDS, called RTPS, and its small brother for constraint devices, short XRCE, are conceptual (more or less) equal.
As further addressing capability nodes can be, independent from topics, organized in
- Groups and
- Participants.
Participants orchestrate groups, which orchestrate endpoints (aka nodes).
And last but not least some highlights /highly dependent on specific implementation):
- maximum message payload size is 64 kB, overhead for protocol is close to 16 bytes (serial DDS)
- services like discovery and sessions are natively supported
- topologies 1 to 0(wait for subscriber), 1 to 1 (P2P) and 1 to n (Star) are supported
- safety is well enabled because
- IDL define maximum required memory (not mandatory require dynamic memory allocation),
- I/O could be well decoupled (no mandatory wait for interrupts)