How do I separate the transport used for discovery data from the transport used for user data?

Note: Applies to RTI Connext version 4.x and above

OMG Data Distribution Service (DDS) applications send two types of data: meta data used for discovery and user data. Because the core of RTI Connext DDS is transport agnostic, it does not make any assumptions about the actual transports used to send and receive messages. This design makes it possible to decouple the transport that is used for each type of data as well as which transport is used by each endpoint. Both the DDS DomainParticipant as well as the DDS DataWriters and DDS DataReaders have an <enabled_transports> QoS property that configures which of the available transports will be used for that particular entity.

The first step to configuring the transport settings in your application is choosing which transports fit the requirements of your system. There are three types of transport plugins. Connext comes with builtin transports (UDPv4, UDPv6, and Shared Memory), offers extension transport plugins (RTI Secure WAN and RTI TCP Transport), and gives you the flexibility to install your own custom transport plugins using the DomainParticipant’s PROPERTY QosPolicy.

Once you have installed and enabled the transports that you want to use in your application, you can configure the <enabled_tranports> property in the DomainParticipant’s DISCOVERY QosPolicy. This property specifies the subset of transports that you want to use during the discovery of other DomainParticipants. And to configure the transports used to communicate between endpoints you can set the <enabled_transports> property in the DataWriter’s and DataReader’s TRANSPORT_SELECTION QosPolicy. The <enabled_transports> properties take a sequence of transport aliases that specify the transport instances available for use by the entity.

The attached XML file, decoupled_transports.xml*, shows an example of how to setup an application that uses the builtin Shared Memory transport for discovery and the builtin UDPv4 transport for user data traffic.

*When running your application with this decoupled_transports.xml configuration file and default initial peers, you will see the following benign error:

can't reach: 
   locator: 
      transport: 1
      address: 0000:0000:0000:0000:0000:0000:EFFF:0001
      port: 22900
      encapsulation:
   transport_priority: 0
   aliasList: "shmem"
can't reach: 
   locator: 
      transport: 1
      address: 0000:0000:0000:0000:0000:0000:EFFF:0001
      port: 22900
      encapsulation:
   transport_priority: 0
   aliasList: "shmem"
can't reach: 
   locator: 
      transport: 1
      address: 0000:0000:0000:0000:0000:0000:EFFF:0001
      port: 22900
      encapsulation:
   transport_priority: 0
   aliasList: "shmem"

Discovery and communication will still occur, and there is a request for enhancement out to change this error to a warning. If you do not want to see this error, you should leave the multicast address off of your initial peers list and set your initial peers list as follows: 

setenv NDDS_DISCOVERY_PEERS shmem://,udpv4://127.0.0.1

Dropping the multicast address from the initial peers causes the multicast_receive_addresses to be left as NULL. The middleware is trying to use the shared memory transport with the default multicast receive address, 239.255.0.1, and this is causing the error.