Open topic with navigation

5.1 Automatic Application Discovery

As you’ve been running the code example described in this guide, you may have noticed that you have not had to start any server processes or configure any network addresses. Its built-in automatic discovery capability is one important way in which Connext DDS differs from other networking middleware implementations. It is designed to be low-overhead and require minimal configuration, so in many cases there is nothing you need to do; it will just work. Nevertheless, it’s helpful to understand the basics so that you can decide if and when a custom configuration is necessary.

Before applications can communicate, they need to “discover” each other. By default, Connext DDS applications discover each other using shared memory or UDP loopback if they are on the same host or using multicast1With the exception of LynxOS. On LynxOS systems, multicast is not used for discovery by default unless NDDS_DISCOVERY_PEERS is set.if they are on different hosts. Therefore, to run an application on two or more computers using multicast, or on a single computer with a network connection, no changes are needed. They will discover each other automatically! The section on Discovery in the RTI Connext DDS Core Libraries User's Manual describes the process in more detail.

If you want to use computers that do not support multicast (or you need to use unicast for some other reason), or if you want to run on a single computer that does not have a network connection (in which case your operating system may have disabled your network stack), there is a simple way to control the discovery process—you won’t even have to recompile. Application discovery can be configured through the NDDS_DISCOVERY_PEERS environment variable or in your QoS configuration file.

5.1.1 When to Set the Discovery Peers

There are only a few situations in which you must set the discovery peers:

(In the following, replace N with the number of Connext DDS applications you want to run.)

  1. If you cannot use multicast2To see if your platform supports multicast, see the RTI Connext DDS Core Libraries Platform Notes.:

Set your discovery peers to a list of all of the hosts that need to discover each other. The list can contain host names and/or IP addresses; each entry should be of the form N@builtin.udpv4://<hostname|IP>.

  1. If you do not have a network connection:

Some operating systems—for example, Microsoft Windows—disable some functionality of their network stack when they detect that no network interfaces are available. This can cause problems when applications try to open network connections.

If your system supports shared memory3To see if your platform supports RTI’s shared memory transport, see the RTI Connext DDS Core Libraries Platform Notes., set your discovery peers to N@builtin.shmem://. This will enable the shared memory transport only.

If your system does not support shared memory (or it is disabled), set your discovery peers to the loopback address, N@builtin.udpv4://127.0.0.1.

5.1.2 How to Set Your Discovery Peers

As stated above, in most cases you do not need to set your discovery peers explicitly.

If setting them is required, there are two easy ways to do so:

ClosedFor example, to turn on shared memory only: 
<participant_qos>
   <discovery>
      <!--
      The initial_peers list are those "addresses" to which the
      middleware will send discovery announcements.
      -->
      <initial_peers>
         <element>4@builtin.shmem://</element>
      </initial_peers>
      <!--
      The multicast_receive_addresses list identifies where the
      DomainParticipant listens for multicast announcements
      from others. Set this list to an empty value to disable
      listening over multicast.
      -->
      <multicast_receive_addresses>
         <!-- empty -->
      </multicast_receive_addresses>
   </discovery>   
   <transport_builtin>
      <!--
      The transport_builtin mask identifies which builtin
      transports the DomainParticipant uses. The default value
      is UDPv4 | SHMEM, so set this mask to SHMEM to prevent
      other nodes from initiating communication with this node
      via UDPv4.
      -->
      <mask>SHMEM</mask>
   </transport_builtin>
   ...
</participant_qos>

For more information, please see the Connext DDS Platform Notes, User’s Manual, and API Reference HTML documentation (from the main page, select Modules, Infrastructure Module, QoS Policies, DISCOVERY).

© 2020 RTI

Open topic with navigation