This diagram shows both phases of the discovery process. Participant A is created first, followed by Participant B. Each has the other in its peers list. After they have discovered each other, a DataWriter is created on Participant A. Periodic participant DATAs, HBs and ACK/NACKs are omitted from this diagram.
Each DomainParticipant needs to be uniquely identified in the DDS domain and specify which other DomainParticipants it is interested in communicating with. The WIRE_PROTOCOL QosPolicy (DDS Extension) uniquely identifies a DomainParticipant in the DDS domain. The DISCOVERY QosPolicy (DDS Extension) specified the peer participants it is interested in communicating with.
There is a trade-off between the amount of traffic on the network for the purposes of discovery and the delay in reaching steady state when the DomainParticipant is first created.
For example, if the DISCOVERY QosPolicy (DDS Extension)’s participant_liveliness_assert_period and participant_liveliness_lease_duration fields are set to small values, the discovery of stale remote DomainParticipants will occur faster, but more discovery traffic will be sent over the network. Setting the participant’s heartbeat_period1heartbeat_period is part of the DDS_RtpsReliableWriterProtocol_t structure used in the See "DISCOVERY QosPolicy (DDS Extension)"’s publication_writer and subscription_writer fields. to a small value can cause late-joining DomainParticipants to discover remote user-data DataWriters and DataReaders at a faster rate, but Connext DDS might send HBs to other nodes more often. This timing can be controlled by the following DomainParticipant QosPolicies:
The other important parameter is the domain ID: DomainParticipants can only discover each other if they belong to the same DDS domain. The domain ID is a parameter passed to the create_participant() operation (see Creating a DomainParticipant).
© 2016 RTI