Chapter 63 Transport Plugins

Connext has a pluggable-transports architecture. The core of Connext is transport agnostic—it does not make any assumptions about the actual transports used to send and receive messages. Instead, Connext uses an abstract "transport API" to interact with the transport plugins that implement that API. A transport plugin implements the abstract transport API, and performs the actual work of sending and receiving messages over a physical transport.

There are essentially three categories of Connext transport plugins:

• Builtin Transport Plugins. Connext comes with a set of commonly used transport plugins that can be enabled using the 56.8 TRANSPORT_BUILTIN QosPolicy (DDS Extension). These ‘builtin’ plugins include UDPv4, UDPv6, shared memory (see Chapter 64 UDPv4, UDPv6, and Shared Memory Transport Plugins), and RTI Real-Time WAN Transport (see Chapter 65 RTI Real-Time WAN Transport). So that Connext applications can work out-of-the-box, some of these transports (UDPv4 and shared memory) are enabled by default, while the others have to be explicitly enabled. Unlike the other two transport classes, the builtin transports can be configured with explicit XML tags under <transport_builtin>. For example, the builtin UDPv4 transport can be configured using the XML tag <udpv4>.
• Extension Transport Plugins. RTI offers one extension transport plugin, Chapter 66 RTI TCP Transport, distributed as an independent library. To work with an extension transport plugin, you must explicitly instantiate and register an instance of it.
• Custom-Developed Transport Plugins. RTI supports the use of custom transport plugins. This is a powerful capability that distinguishes Connext from competing middleware approaches. If you are interested in developing a custom transport plugin for Connext, please contact your local RTI representative or email sales@rti.com.

This chapter includes the following sections: