15.2 Configuring the Peers List Used in Discovery

As part of the participant phase of the discovery process, Connext DDS will announce itself within the DDS domain. Connext DDS will try to contact all possible participants in the ‘initial peers list,’ specified in the DomainParticipant’s 9.5.2 DISCOVERY QosPolicy (DDS Extension). Note, however, it is not known if there are actually Connext DDS applications running on the hosts in the inital peers list. The initial peers list may include both unicast and multicast peer locators.

After startup, you can add to the ‘peers list’ with the add_peer() operation (see 9.5.2.3 Adding and Removing Peers List Entries). The ‘peers list’ may also grow as peers are automatically discovered (if accept_unknown_peers is TRUE, see 9.5.2.6 Controlling Acceptance of Unknown Peers).

When you call get_default_participant_qos() for a DomainParticipantFactory, the values used for the DiscoveryQosPolicy’s initial_peers and multicast_receive_addresses may come from the following:

If NDDS_DISCOVERY_PEERS (file or environment variable) does not contain a multicast address, then multicast_receive_addresses is cleared and the RTI discovery process will not listen for discovery messages via multicast.

If NDDS_DISCOVERY_PEERS (file or environment variable) contains one or more multicast addresses, the addresses are stored in multicast_receive_addresses, starting at element 0. They will be stored in the order in which they appear in NDDS_DISCOVERY_PEERS.

Note: Setting initial_peers in the default XML QoS Profile does not modify the value of multicast_receive_address.

If both the file and environment variable are found, the file takes precedence and the environment variable will be ignored.1This is true even if the file is empty. The settings in the default XML QoS Profile take precedence over the file and environment variable. In the absence of a file, environment variable, or default XML QoS profile values, Connext DDS will use a default value. See the API Reference HTML documentation for details (in the section on the DISCOVERY QosPolicy).

If initial peers are specified in both the currently loaded QoS XML profile and in the NDDS_DISCOVERY_PEERS file, the values in the profile take precedence.

The file, environment variable, and default XML QoS Profile make it easy to reconfigure which nodes will take part in the discovery process—without recompiling your application.

The file, environment variable, and default XML QoS Profile are the possible sources for the default initial peers list. You can, of course, explicitly set the initial list by changing the values in the QoS provided to the DomainParticipantFactory's create_participant() operation, or by adding to the list after startup with the DomainParticipant’s add_peer() operation (see 9.5.2.3 Adding and Removing Peers List Entries).

If you set NDDS_DISCOVERY_PEERS and You Want to Communicate over Shared Memory:

Suppose you want to communicate with other Connext DDS applications on the same host and you are explicitly setting NDDS_DISCOVERY_PEERS (generally in order to use unicast discovery with applications on other hosts).

If the local host platform does not support the shared memory transport, then you can include the name of the local host in the NDDS_DISCOVERY_PEERS list. (To check if your platform supports shared memory, see the RTI Connext DDS Core Libraries Platform Notes.)

If the local host platform supports the shared memory transport, then you must do one of the following:

or:

© 2020 RTI