XML QoS Example for using the RTI Connext DDS TCP transport

Note: This XML works in RTI Connext DDS 5.0.0 or higher.  Previous versions do not support merging of Participant properties in XML.  To make this example work in pre-5.0.0 versions, copy the Participant properties from the base profile into the Publisher and Subscriber profiles.  

By default, RTI Connext DDS uses the UDPv4 and Shared Memory transport to communicate with other DDS applications. In some circumstances, the TCP protocol might be needed for discovery and data exchange. For more information on the RTI TCP Transport, please refer to the section in the RTI Core Libraries and Utilities User Manual titled "RTI TCP Transport".

This solution shows a minimal example of XML for enabling RTI Connext DDS to communicate using only the TCP transport. This example disables the built-in shared memory and UDP transports. 

There are some important aspects related to this example:

1. TCP in a LAN

This profile is configured to send data using TCP within a local area network.  This is specified in two places.

1. In the initial peers we use in this file specify "tcpv4_lan://"  
2. The transport class ID that is set to "NDDS_TRANSPORT_CLASSID_TCPV4_LAN"

2. TCP in symmetric mode

This example is configured to allow DomainParticipants to communicate symmetrically.  This means that for any pair of DomainParticipants, either DomainParticipant is allowed to start the communication.  This can be contrasted with asymmetric mode, where one DomainParticipant is set up as the Server which waits for a Client to initiate the connection.  In symmetric mode, all DomainParticipants must specify both the local port they are listening on, and the initial peers they are contacting.

3. Initial peers and local ports in the TCP transport 

Note that in this example, the Publisher and Subscriber applications are explicitly loading two separate profiles.  The XML specifies that the DomainParticipant in the Publisher application will listen on port 7100 and the DomainParticipant in the Subscriber application will listen on port 7001.  If you start more applications on the same machine using this file, only the first one that gets the port will succeed at binding it. You must use a different XML setting for each application on the same machine, or change the code to set DomainParticipant properties to use a different port.

<element>
    <name>dds.transport.TCPv4.tcp1.server_bind_port</name>
    <value>7100</value> 
</element> 

This file also specifies that the DomainParticipant will contact a remote DomainParticipant at address localhost:7101 and localhost:7100 (depending on Publisher or Subscriber application). When testing, change this value to the actual IP address and port of the machines you want to test on.

<initial_peers>
    <element>tcpv4_lan://localhost:7101</element> 
</initial_peers>