Discovery Traffic Summary

You are here:

Discovery Traffic Summary

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.

Discovery-Related QoS

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:

DISCOVERY QosPolicy (DDS Extension) — specifies how other DomainParticipants in the network can communicate with this DomainParticipant, and which other DomainParticipants in the network this DomainParticipant is interested in communicating with. See also: Ports Used for Discovery.
DISCOVERY_CONFIG QosPolicy (DDS Extension) — specifies the QoS of the discovery readers and writers (parameters that control the HB and ACK rates of discovery endpoint readers/writers, and periodic refreshing of participant DATA from discovery participant readers/writers). It also allow you to configure asynchronous writers in order to send data with a larger size than the transport message size.
DOMAIN_PARTICIPANT_RESOURCE_LIMITS QosPolicy (DDS Extension) — specifies the number of local and remote entities expected in the system.
WIRE_PROTOCOL QosPolicy (DDS Extension) — specifies the rtps_app_id and rtps_host_id that uniquely identify the participant in the DDS domain.

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).