1. Introduction
RTI® Cloud Discovery Service is a stand-alone application that deploys RTI Connext® applications in dynamic environments where UDP/IP multicast is not available. This is typical of wide-area networks or some cloud-based environments where the routers and switches may disable IP multicast forwarding. Cloud Discovery Service also works in conjunction with the RTI Real-Time WAN Transport to provide peer-to-peer communication between DomainParticipants situated behind Network Address Translators (NATs).
DDS has a builtin Discovery Service that allows all DDS applications to automatically detect the presence of other applications and discover the Topics they publish and subscribe along with the associated data types and Quality of Service (QoS).
The builtin discovery service primarily relies on UDP/IP multicast to bootstrap the detection of other DDS applications and learn their network addresses. The use of UDP/IP multicast allows DDS discovery to be completely peer-to-peer. That is, it can operate without requiring any additional services or brokers. The applications themselves can discover each other directly.
However, if Connext applications run in environments where UDP/IP multicast is not available, then builtin (peer-to-peer) discovery is not sufficient. Connext offers two mechanisms to help with those scenarios:
For static environments where the network addresses of all 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 about the presence and network addresses of other DDS applications. You can do this by setting the Initial Peers to include Cloud Discovery Service.
For WAN deployments where applications require Network Address Translator (NAT) traversal. Cloud Discovery Service can aid in this process in combination with RTI Real-Time WAN Transport. See RTI Real-Time WAN Transport.
Figure 1.1 Cloud Discovery Service Overview
Figure 1.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.
1.1. The Basics
Cloud Discovery Service operates using the default Simple Participant Discovery Protocol (SPDP) 1 or the new Simple Participant Discovery Protocol 2.0 (SPDP2) 2. In either case, DomainParticipants initially announce their presence to all the specified Initial Peers. These participant announcements contain the necessary information for other DomainParticipants to discover their presence and bootstrap communications. In Simple Participant Discovery Protocol, these messages are also used to maintain participant liveliness.
Figure 1.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 1.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 themselves.
Figure 1.3 DomainParticipants exchange Participant Announcement messages
Figure 1.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 1.4 DomainParticipants exchange Endpoint Discovery messages
Figure 1.4 illustrates that once DomainParticipants know about each other, they exchange Endpoint discovery information. That is, they exchange information about the DataWriters and DataReaders each one has. This step is unaltered by the presence of Cloud Discovery Service.
Direct benefits of Cloud Discovery Service:
Dynamic discovery remains possible even if multicast is not available, without the need to anticipate or maintain a list of peers.
Cloud Discovery Service integrates seamlessly in a DDS environment. Because it operates at the RTPS 3 level, Connext applications do not need any special behavior or protocol. They just need to configure their Initial Peers to contain the location where Cloud Discovery Service is running. Since this is all configurable at runtime, there is no need to recompile your application. This implies that Cloud Discovery Service will also work with existing services such as RTI Routing Service, RTI Connext Micro, or other implementations of DDS-RTPS.
Discovery remains a distributed process performed among all the DomainParticipants. This allows you to scale the system dynamically. It also avoids having centralized and bottleneck servers.
For a deeper understanding of discovery, refer to Discovery Overview in the RTI Connext Core Libraries User’s Manual.
1.2. Available Documentation
In this manual you can find:
1.3. Paths Mentioned in Documentation
This documentation refers to:
<NDDSHOME>
This refers to the installation directory for Connext. The default installation paths are:macOS® systems:
/Applications/rti_connext_dds-version
Linux® systems, non-root user:
/home/your user name/rti_connext_dds-version
Linux systems, root user:
/opt/rti_connext_dds-version
Windows® systems, user without Administrator privileges:
<your home directory>\rti_connext_dds-version
Windows systems, user with Administrator privileges:
C:\Program Files\rti_connext_dds-version
You may also see
$NDDSHOME
or%NDDSHOME%
, which refers to an environment variable set to the installation path.Whenever you see
<NDDSHOME>
used in a path, replace it with your installation path.Note for Windows Users: When using a command prompt to enter a command that includes the path
C:\Program Files
(or any directory name that has a space), enclose the path in quotation marks. For example:“C:\Program Files\rti_connext_dds-version\bin\rticlouddiscoveryservice.bat”
Or if you have defined the
NDDSHOME
environment variable:"%NDDSHOME%\bin\rticlouddiscoveryservice.bat"
<path to examples>
By default, examples are copied into your home directory the first time you run RTI Launcher or any script in<NDDSHOME>/bin
. This document refers to the location of the copied examples as<path to examples>
.Wherever you see
<path to examples>
, replace it with the appropriate path. Default path to the examples:macOS systems:
/Users/your user name/rti_workspace/version/examples
Linux systems:
/home/your user name/rti_workspace/version/examples
Windows systems:
your Windows documents folder\rti_workspace\version\examples
. Where'your Windows documents folder'
depends on your version of Windows. For example, on Windows 7, the folder isC:\Users\your user name\Documents
; on Windows Server 2003, the folder isC:\Documents and Settings\your user name\Documents
.
<RTIMEHOME>
This environment variable must be set to the installation directory path for Connext Micro. If you installed Connext Professional with default settings, this will be in:<path_to_connext_dds_installation>/rti_connext_dds-version/rti_connext_micro-version
. If you have copied Connext Micro to another place, setRTIMEHOME
to point to that location.
References
- 1
Simple Participant Discovery Protocol discovers all other DomainParticipants in the same DDS Domain by sending participant announcements. Such announcements include the DomainParticipant unique identifying key, transport locators, and QoS. These announcements are sent on a periodic basis using best-effort communication.
- 2
Simple Participant Discovery Protocol 2.0 is an alternative to the original Simple Participant Discovery Protocol. SPDP2 is designed to decrease bandwidth usage and improve the reliability of the participant discovery and update process.
- 3
Real-Time Publish-Subscribe Protocol