Fast DDS, as a Data Distribution Service (DDS) implementation, provides discovery mechanisms that allow for automatically finding and matching DataWriters and DataReaders across DomainParticipants so they can start sharing data. This discovery is performed, for all the mechanisms, in two phases.
5.1. Discovery phases¶
Participant Discovery Phase (PDP): During this phase the
DomainParticipantsacknowledge each other’s existence. To do that, each DomainParticipant sends periodic announcement messages, which specify, among other things, unicast addresses (IP and port) where the DomainParticipant is listening for incoming meta and user data traffic. Two given DomainParticipants will match when they exist in the same DDS Domain. By default, the announcement messages are sent using well-known multicast addresses and ports (calculated using the
DomainId). Furthermore, it is possible to specify a list of addresses to send announcements using unicast (see in Initial peers). Moreover, is is also possible to configure the periodicity of such announcements (see Discovery Configuration).
Endpoint Discovery Phase (EDP): During this phase, the
DataReadersacknowledge each other. To do that, the DomainParticipants share information about their DataWriters and DataReaders with each other, using the communication channels established during the PDP. This information contains, among other things, the
Topicand data type (see Topic). For two endpoints to match, their topic and data type must coincide. Once DataWriter and DataReader have matched, they are ready for sending/receiving user data traffic.
It is possible to use the PDP phase to transmit information about the host, user, and process (physical information)
in which the
DomainParticipant is running.
Please refer to Physical Data in Discovery Information for more information about how to configure the transmitted
5.2. Discovery mechanisms¶
Fast DDS provides the following discovery mechanisms:
Simple Discovery: This is the default mechanism. It upholds the RTPS standard for both PDP and EDP, and therefore provides compatibility with any other DDS and RTPS implementations.
Static Discovery: This mechanisms uses the Simple Participant Discovery Protocol (SPDP) for the PDP phase (as specified by the RTPS standard), but allows for skipping the Simple Endpoint Discovery Protocol (SEDP) phase when all the DataWriters’ and DataReaders’ IPs and ports, data types, and Topics are known beforehand.
Discovery Server: This discovery mechanism uses a centralized discovery architecture, where a DomainParticipant, referred as Server, acts as a hub for meta traffic discovery.
Manual Discovery: This mechanism is only compatible with the RTPS layer. It disables the PDP, letting the user to manually match and unmatch
RTPSWritersusing whatever external meta-information channel of its choice. Therefore, the user must access the RTPSParticipant implemented by the DomainParticipant and directly match the RTPS Entities.
5.3. Discovery settings¶
The following sections list and describe the settings available for each of the previously defined discovery mechanisms, as well as how to define the DomainParticipantListener discovery callbacks.
- 5.3.1. General Discovery Settings
- 5.3.2. SIMPLE Discovery Settings
- 5.3.3. STATIC Discovery Settings
- 5.3.4. Discovery Server Settings
- 220.127.116.11. Key concepts
- 18.104.22.168. Choosing between Client and Server
- 22.214.171.124. The GuidPrefix as the server unique identifier
- 126.96.36.199. The server locator list
- 188.8.131.52. Fine tuning discovery server handshake
- 184.108.40.206. Modifying remote servers list at run time
- 220.127.116.11. Configure Discovery Server locators using names
- 18.104.22.168. Full example
- 5.3.5. DomainParticipantListener Discovery Callbacks