Open topic with navigation
When a DomainParticipant is created, a DataWriter and a DataReader are automatically created to exchange participant DATA messages in the network. These DataWriters and DataReaders are "special" because the DataWriter can send to a given list of destinations, regardless of whether there is a Connext DDS application at the destination, and the DataReader can receive data from any source, whether the source is previously known or not. In other words, these special readers and writers do not need to discover the remote entity and perform a match before they can communicate with each other.
When a DomainParticipant joins or leaves the network, it needs to notify its peer participants. The list of remote participants to use during discovery comes from the peer list described in the DISCOVERY QosPolicy (DDS Extension). The remote participants are notified via participant DATA messages. In addition, if a participant’s QoS is modified in such a way that other participants need to know about the change (that is, changes to the USER_DATA QosPolicy), a new participant DATA will be sent immediately.
Participant DATAs are also used to maintain a participant’s liveliness status. These are sent at the rate set in the participant_liveliness_assert_period in the DISCOVERY_CONFIG QosPolicy (DDS Extension).
Let’s examine what happens when a new remote participant is discovered. If the new remote participant is in the local participant's peer list, the local participant will add that remote participant into its database. If the new remote participant is not in the local application's peer list, it may still be added, if the accept_unknown_peers field in the DISCOVERY QosPolicy (DDS Extension) is set to TRUE.
Once a remote participant has been added to the Connext DDS database, Connext DDS keeps track of that remote participant’s participant_liveliness_lease_duration. If a participant DATA for that participant (identified by the GUID) is not received at least once within the participant_liveliness_lease_duration, the remote participant is considered stale, and the remote participant, together with all its entities, will be removed from the database of the local participant.
To keep from being purged by other participants, each participant needs to periodically send a participant DATA to refresh its liveliness. The rate at which the participant DATA is sent is controlled by the participant_liveliness_assert_period in the participant’s DISCOVERY_CONFIG QosPolicy (DDS Extension). This exchange, which keeps Participant A from appearing ‘stale,’ is illustrated in Figure: Periodic ‘participant DATAs’. Figure: Ungraceful Termination of a Participant shows what happens when Participant A terminates ungracefully and therefore needs to be seen as ‘stale.’
Figure: Periodic ‘participant DATAs’
The DomainParticipant on Node A sends a ‘participant DATA’ to Node B, which is in Node A’s peers list. This occurs regardless of whether or not there is a Connext DDS application on Node B.
<![CDATA[ ]]>The green short dashed lines are periodic participant DATAs. The time between these messages is controlled by the participant_liveliness_assert_period in the DiscoveryConfig QosPolicy.
k <![CDATA[ ]]>In addition to the periodic participant DATAs, ‘initial repeat messages’ (shown in blue, with longer dashes) are sent from A to B. These messages are sent at a random time between min_initial_participant_announcement_period and max_initial_participant_announcement_period (in A’s DiscoveryConfig QosPolicy). The number of these initial repeat messages is set in initial_participant_announcements.
Figure: Ungraceful Termination of a Participant
Participant A is removed from participant B’s database if it is not refreshed within the liveliness lease duration. Dashed lines are periodic participant DATA messages.
(Periodic resends of ‘participant B DATA’ from B to A are omitted from this diagram for simplicity. Initial repeat messages from A to B are also omitted from this diagram—these messages are sent at a random time between min_initial_participant_announcement_period and max_initial_participant_announcement_period, see Figure: Periodic ‘participant DATAs’.)
To ensure that a late-joining participant does not need to wait until the next refresh of the remote participant DATA to discover the remote participant, there is a resend mechanism. If the received participant DATA is from a never-before-seen remote participant, and it is in the local participant's peers list, the application will resend its own participant DATA to all its peers. This resend can potentially be done multiple times, with a random sleep time in between. Figure: Resending ‘participant DATA’ to a Late-Joiner illustrates this scenario.
The number of retries and the random amount of sleep between them are controlled by each participant’s DISCOVERY_CONFIG QosPolicy (DDS Extension) (see Figure: Resending ‘participant DATA’ to a Late-Joiner ).
Figure: Resending ‘participant DATA’ to a Late-Joiner
Participant A has Participant B in its peers list. Participant B does not have Participant A in its peers list, but [DiscoveryQosPolicy.accept_unknown_peers] is set to DDS_BOOLEAN_TRUE. Participant A joins the system after B has sent its initial announcement. After B discovers A, it waits for time Á, then resends its participant DATA.
(Initial repeat messages are omitted from this diagram for simplicity, see Figure: Periodic ‘participant DATAs’.)
Figure: Participant Discovery Summary provides a summary of the messages sent during the participant discovery phase.
Figure: Participant Discovery Summary
Participants A and B both have each other in their peers lists. Participant A is created first.
To maintain the liveliness of DataWriters that have a LIVELINESS QosPolicy kind field set to AUTOMATIC or MANUAL_BY_PARTICIPANT, Connext DDS uses a built-in DataWriter and DataReader pair, referred to as the inter-participant reader and inter-participant writer.
If the DomainParticipant has any DataWriters with Liveliness QosPolicy kind set to AUTOMATIC, the inter-participant writer will reliably broadcast an AUTOMATIC liveliness message at a period equal to the shortest lease_duration of these DataWriters. (The lease_duration is a field in the LIVELINESS QosPolicy.) Figure: DataWriter with AUTOMATIC Liveliness illustrates this scenario.
Figure: DataWriter with AUTOMATIC Liveliness
A liveliness message is sent automatically when a DataWriter with AUTOMATIC Liveliness kind is created, and then periodically, every DDS_DataWriterQos.liveliness.lease_duration.
If the DomainParticipant has any DataWriters with Liveliness QosPolicy kind set to MANUAL_BY_PARTICIPANT, <![CDATA[ ]]>Connext DDS will periodically check to see if any of them have called write(), assert_liveliness(), dispose() or unregister(). The rate of this check is every X seconds, where X is the smallest lease_duration among all the DomainParticipant's MANUAL_BY_PARTICIPANT DataWriters. (The lease_duration is a field in the LIVELINESS QosPolicy.) If any of the MANUAL_BY_PARTICIPANT DataWriters have called any of those operations, the inter-participant writer will reliably broadcast a MANUAL liveliness message.
If a DomainParticipant's assert_liveliness() operation is called, and that DomainParticipant has any MANUAL_BY_PARTICIPANT DataWriters, the inter-participant writer will reliably broadcast a MANUAL liveliness message within the above-defined X time period. These MANUAL liveliness messages are used to update the liveliness of all the DomainParticipant's MANUAL_BY_PARTICIPANT DataWriters, as well as the liveliness of the DomainParticipant itself. Figure: DataWriter with MANUAL_BY_PARTICIPANT Liveliness shows an example sequence.
Figure: DataWriter with MANUAL_BY_PARTICIPANT Liveliness
Once a MANUAL_BY_PARTICIPANT DataWriter is created, subsequent calls to assert_liveliness, write, dispose, or unregister_instance will trigger Liveliness messages, which update the liveliness status of all the participant’s DataWriters, and the participant itself.
The inter-participant reader receives data from remote inter-participant writers and asserts the liveliness of remote DomainParticipants endpoints accordingly.
If the DomainParticipant has no DataWriters with LIVELINESS QosPolicy kind set to AUTOMATIC or MANUAL_BY_PARTICIPANT, then no liveliness messages are ever sent from the inter-participant writer.
© 2018 RTI
Open topic with navigation