Cloud Discovery Service

Connext offers two mechanisms to help with those scenarios:

• For static environments where the network addresses of the applications are known a-priori, you can configure your application to automatically check on these addresses for the presence of other applications. This is accomplished by configuring the Initial Peers.
• For dynamic environments where the network addresses are not known in advance, or in cases where the list is too large or cumbersome to manage, you can leverage RTI Cloud Discovery Service. This external service acts as a reliable “rendezvous” point for Connext applications to learn the presence and network addresses of other DDS applications. This can be accomplished by setting the Initial Peers to include Cloud Discovery Service.

Figure 1. Cloud Discovery Service Overview

Figure 1 shows a simple representation of the operation of Cloud Discovery Service. It acts as a “relay” service that forwards the bootstrap (participant announcement) messages that allow DomainParticipants to learn about the presence of other DomainParticipants.

The Basics

Cloud Discovery Service operates using the standard Simple Discovery Protocol (SDP) ^[1]. In SDP, DomainParticipants initially announce their presence to all of the specified Initial Peers. These participant announcements contain the necessary information for other DomainParticipants to discover their presence and bootstrap communications. These messages are also used to maintain participant liveliness.

Figure 2. Cloud Discovery Service Forwards Participant Announcement Messages

Cloud Discovery Service listens for participant announcements to dynamically learn about the current list of DomainParticipants, their DDS domain IDs and their network addresses.

Figure 2 illustrates that each DomainParticipant includes a Cloud Discovery Service instance in its Initial Peers. Hence, the DomainParticipant will send participant announcements to Cloud Discovery Service, which will forward those announcements to the list of DomainParticipants it knows about, enabling them to initiate the discovery process among them.

Figure 3. DomainParticipants Exchange Participant Announcement Messages

Figure 3 illustrates that once a DomainParticipant discovers the presence of another one (via the forwarded message from Cloud Discovery Service) it sends its Participant Announcement messages directly. This step is the same as if the DomainParticipant had included the other DomainParticipant in its Initial Peers or was using multicast to announce its presence. These messages are also used to maintain participant liveliness.

Figure 3 shows that once a DomainParticipant receives an announcement from another one forwarded by Cloud Discovery Service, it can directly send participant announcements. This step is the same as if the DomainParticipant included the other DomainParticipant in its Initial Peers or used multicast to announce its presence.

Figure 4. Domain Participants Exchange Endpoint Discovery Messages

Figure 4 illustrates that once DomainParticipants know about each other, they exchange Endpoint discovery information. That is, information on the DataWriters and DataReaders each has. This step is unaltered by the presence of Cloud Discovery Service.

For a deeper understanding of discovery, refer to the What is Discovery? section in the RTI Connext Users Manual.