About This Architecture

DDS Service Discovery implements a two-phase principle where DomainParticipants A, B, and C first discover each other via SPDP multicast on 239.255.0.1:7400, then exchange Writer and Reader endpoint information through a shared Service Discovery Table. After participant discovery, the Writer sends data directly to Reader endpoints (192.168.1.20:7410 and 192.168.1.30:7410) with no forwarding overhead, enabling low-latency peer-to-peer communication. This architecture demonstrates how DDS achieves dynamic discovery and direct data flow in distributed real-time systems, critical for mission-critical applications requiring deterministic latency and fault tolerance. Fork this diagram on Diagrams.so to customize multicast groups, add QoS policies, or model failover scenarios for your DDS deployment. The design handles dynamic readers going offline—DP-C notifies DP-A to update the discovery table—making it ideal for systems with mobile or intermittent participants.

People also ask

How does DDS Service Discovery work and what are the two phases of participant and endpoint discovery?

DDS Service Discovery operates in two phases: Phase 1 uses SPDP multicast on 239.255.0.1:7400 where all DomainParticipants announce themselves and discover peers; Phase 2 exchanges Writer and Reader endpoint information via a Service Discovery Table. After discovery, Writers send data directly to Reader IP:Port addresses with no forwarding, enabling deterministic low-latency communication in distr