The RTI TCP Transport enables communication between RTI Connext applications using TCP. The communication can be either over a LAN or over a WAN.

Available Documentation

This document contains:

For additional information, please see the following PDF document:

RTI Connext DDS Core Libraries User's Manual

Overview

Out of the box, RTI Connext uses UDP and Shared Memory to communicate with other DDS applications. This configuration is appropriate for systems running within a single LAN. However, using the UDP transport introduces some problems when DDS applications in different LANs need to communicate:

UDP traffic is usually filtered out by the LAN firewalls for security reasons.
Forwarded ports are usually TCP ports.
Each LAN may run in its own private IP address space and use NAT (Network Address Translation) to communicate with other networks.

RTI TCP Transport enables participant discovery and data exchange using the TCP protocol either on a LAN, or over the public WAN. RTI TCP Transport enables RTI Connext to address the challenges of using TCP as a low-level communication mechanism between peers and limits the number of exposed ports to one. When using the default UDP transport, an RTI Connext application uses multiple UDP ports for communication, which may make
it unsuitable for deployment across firewalled networks.

Configuring the TCP Transport

The TCP transport is distributed as a shared library located under <RTI Connext installation directory>/lib/<architecture>. The library is called nddstransporttcp.

There are two ways in which this transport can be configured:

By setting up predefined property strings in the Property QoS Policy of the DomainParticipant (on architectures that support shared libraries).

Refer to Configure TCP Transport with Property QoS Policy for the predefined property strings.

With this first approach, RTI Connext will dynamically load the TCP transport library at run time and then implicitly create and register the transport plugin.

(Shared libraries are supported on all architectures except INTEGRITY and certain VxWorks platforms. For VxWorks, dynamic libraries are only supported for architectures that are on Pentium/Arm CPUs AND use kernel mode.)
By instantiating a new transport and registering it with the DomainParticipant (available in C/C++ API only).

Refer to NDDS_Transport_TCPv4_new for information on how to create a new TCP transport instance.

Refer to NDDS_Transport_Support_register_transport for documentation on how to register the transport instance with RTI Connext.

To use this second approach, you need access to the TCP Transport Plugin API at compile time. Your application will have to include the following header file:

#include "ndds/transport_tcp/transport_tcp_tcpv4.h"
```
(The above path assumes that RTI TCP Transport is installed in the same directory as RTI Connext.)
```

Regardless of which way is used to configure the TCP transport, you will need to specify TCP as the transport in the initial peers. See TCP Transport Initial Peers for details.