28.2 Endpoint Discovery

The discovery process may change depending on the communication method. The usual communication is between a DataWriter and one or more DataReaders. For this kind, Connext will use Simple Endpoint Discovery. However, there are other communication methods like RPC and Request/Reply that need more sophisticated discovery processes. Request/Reply and RPC endpoint discovery are covered in 47.3 Request-Reply Endpoint Discovery.

As seen in Figure 28.1: Built-in Writers and Readers for Discovery, reliable DataReaders and Datawriters are automatically created to exchange publication/subscription information for each DomainParticipant. We will refer to these as ‘discovery endpoint readers and writers.’ However, nothing is sent through the network using these entities until they have been ‘matched’ with their remote counterparts. This ‘matching’ is triggered by the Participant Discovery phase. The goal of the Endpoint Discovery phase is to add the remote endpoint to the local database, so that user-created endpoints (your application’s DataWriters/DataReaders) can communicate with each other.

When a new remote DomainParticipant is discovered and added to a participant’s database, Connext assumes that the remote DomainParticipant is implemented in the same way and therefore is creating the appropriate counterpart entities. Therefore, Connext will automatically add two remote discovery endpoint readers and two remote discovery endpoint writers for that remote DomainParticipant into the local database. Once that is done, there is now a match with the local discovery endpoint writers and readers, and publication DATAs and subscription DATAs can then be sent between the discovery endpoint readers/writers of the two DomainParticipant.

When you create a DataWriter/DataReader for your user data, a publication/subscription DATA describing the newly created object is sent from the local discovery endpoint writer to the remote discovery endpoint readers of the remote DomainParticipants that are currently in the local database.

If your application changes any of the following QosPolicies for a local user-data DataWriter/DataReader, a modified subscription/publication DATA is sent to propagate the QoS change to other DomainParticipants:

What the above QosPolicies have in common is that they are all changeable and part of the builtin data (see Chapter 31 Accessing Discovery Information through Built-In Topics). Note that if TypeObject v2 is used as the wire representation (which it is by default in Connext), these DATA samples contain just a hash of the type being used by the endpoints. If TypeObject v1 is used, each update sent using the builtin DataReaders and DataWriters contains the entire serialized type.

Similarly, if the application deletes any user-data writers/readers, the discovery endpoint writer/readers send delete publication/subscription DATAs. In addition to sending publication/subscription DATAs, the discovery endpoint writer will check periodically to see if the remote discovery endpoint reader is up-to-date. (The rate for this check is the publication_writer.heartbeat_period or subscription_writer.heartbeat_period in the 56.3 DISCOVERY_CONFIG QosPolicy (DDS Extension). If the discovery endpoint writer has not been acknowledged by the remote discovery endpoint reader regarding receipt of the latest DATA, the discovery endpoint writer will send a special Heartbeat (HB) message with the Final bit set to 0 (F=0) to request acknowledgement from the remote discovery endpoint reader, as seen in Figure 28.8: Endpoint Discovery Summary.

Figure 28.8: Endpoint Discovery Summary

 

 

Assume participants A and B have been discovered on both sides. A’s DiscoveryConfigQosPolicy.publication_writer.heartbeats_per_max_samples = 0, so no HB is piggybacked with the publication DATA. A HB with F=0 is a request for an ACK/NACK. The periodic and initial repeat participant DATAs are omitted from the diagram.

Discovery endpoint writers and readers have their 59.12 HISTORY QosPolicy set to KEEP_LAST, and their 59.9 DURABILITY QosPolicy set to TRANSIENT_LOCAL. Therefore, even if the remote DomainParticipant has not yet been discovered at the time the local user’s DataWriter/DataReader is created, the remote DomainParticipant will still be informed about the previously created DataWriter/DataReader. This is achieved by the HB and ACK/NACK that are immediately sent by the builtin endpoint writer and builtin endpoint reader respectively when a new remote participant is discovered. Figure 28.9: DataWriter Discovered by Late-Joiner, Triggered by HB and Figure 28.10: DataWriter Discovered by Late-Joiner, Triggered by ACKNACK illustrate this sequence for HB and ACK/NACK triggers, respectively.

Figure 28.9: DataWriter Discovered by Late-Joiner, Triggered by HB

Writer C is created on Participant A before Participant A discovers Participant B. Assuming DiscoveryConfigQosPolicy.publication_writer.heartbeats_per_max_samples = 0, no HB is piggybacked with the publication DATA. Participant B has A in its peer list, but not vice versa. Accept_unknown_locators is true. On A, in response to receiving the new participant B DATA message, a participant A DATA message is sent to B. The discovery endpoint reader on A will also send an ACK/NACK to the discovery endpoint writer on B. (Initial repeat participant messages and periodic participant messages are omitted from this diagram for simplicity, see Figure 28.2: Periodic ‘participant DATAs’ in 28.1 Participant Discovery.)

Figure 28.10: DataWriter Discovered by Late-Joiner, Triggered by ACKNACK

Writer C is created on Participant A before Participant A discovers Participant B. Assuming DiscoveryConfigQosPolicy.publication_writer.heartbeats_per_max_samples = 0, no HB is piggybacked with the publication DATA message. Participant A has B in its peer list, but not vice versa. Accept_unknown_locators is true. In response to receiving the new Participant A DATA message on node B, a participant B DATA message will be sent to A. The discovery endpoint writer on Node B will also send a HB to the discovery endpoint reader on Node A. These are omitted in the diagram for simplicity. (Initial repeat participant messages and periodic participant messages are omitted from this diagram, see Figure 28.2: Periodic ‘participant DATAs’ in 28.1 Participant Discovery.)

Endpoint discovery latency is determined by the following members of the DomainParticipant’s 56.3 DISCOVERY_CONFIG QosPolicy (DDS Extension):

  • publication_writer
  • subscription_writer
  • publication_reader
  • subscription_reader

When a remote entity record is added, removed, or changed in the database, matching is performed with all the local entities. Only after there is a successful match on both ends can an application’s user-created DataReaders and DataWriters communicate with each other.

For more information about reliable communication, see Chapter 35 Reliability Models for Sending Data.