Transport Use Cases

Working with pluggable transports. More...

Working with pluggable transports.

Changing the automatically registered built-in transports

• The DDS_TRANSPORTBUILTIN_MASK_DEFAULT specifies the transport plugins that will be automatically registered with a newly created DDSDomainParticipant by default.

• This default can be changed by changing the value of the value of TRANSPORT_BUILTIN Qos Policy on the DDSDomainParticipant

• To change the DDS_DomainParticipantQos::transport_builtin Qos Policy:

Changing the properties of the automatically registered builtin transports

The behavior of the automatically registered builtin transports can be altered by changing their properties.

• Tell the DDSDomainParticipantFactory to create the participants disabled, as described in Turning off auto-enable of newly created participant(s)

• Get the property of the desired builtin transport plugin, say ::NDDS_Transport_UDPv4_Plugin

• Change the property fields as desired. Note that the properties should be changed carefully, as inappropriate values may prevent communications. For example, the ::NDDS_Transport_UDPv4_Plugin properties can be changed to support large messages (assuming the underlying operating system's UDPv4 stack supports the large message size). Note: if message_size_max is increased from the default for any of the built-in transports, then the DDS_ReceiverPoolQosPolicy::buffer_size on the DomainParticipant should also be changed.

• Set the property of the desired builtin transport plugin, say ::NDDS_Transport_UDPv4_Plugin

• Enable the participant to turn on communications with other participants in the domain using the new properties for the automatically registered builtin transport plugins.

Creating a transport

• A transport plugin is created using methods provided by the supplier of the transport plugin.

• For example to create an instance of the ::NDDS_Transport_UDPv4_Plugin

Deleting a transport

• A transport plugin can only be deleted only after the DDSDomainParticipant with which it is registered is deleted.

• The virtual destructor provided by the abstract transport plugin API can be used to delete a transport plugin.

Registering a transport with a participant

The basic steps for setting up transport plugins for use in an RTI Connext application are described below.

• Tell the DDSDomainParticipantFactory to create the participants disabled, as described in Turning off auto-enable of newly created participant(s)

• [Optionally] Changing the automatically registered built-in transports

• [Optionally] Changing the properties of the automatically registered builtin transports

• Create a disabled DDSDomainParticipant, as described in Setting up a participant

• Decide on the network address for the transport plugin. The network address should be chosen so that the resulting fully qualified address is globally unique (across all transports used in the domain).

• Decide on the aliases for the transport plugin. An alias can refer to one or more transport plugins. The transport class name (see Builtin Transport Class Names) are automatically appended to the user-provided aliases. Alias names are useful in creating logical groupings of transports, e.g. all the transports that are configured to support large messages may be given the alias "large_message".

• Register the transport plugin with the DDSDomainParticipant. Note that a transport plugin should NOT be registered with more than one DomainParticipant. It is the responsibility of the application programmer to ensure that this requirement is not violated.

• [Optionally] Adding receive routes for a transport

• [Optionally] Adding send routes for a transport

• Enable the participant to turn on communications with other participants in the domain, using the newly registered transport plugins, and automatically registered builtin transport plugins (if any).

Adding receive routes for a transport

• Receive routes can be added to restrict address ranges on which incoming messages can be received. Any number of receive routes can be added, but these must be done before the participant is enabled.

• To restrict the address range from which incoming messages can be received by the transport plugin:

Adding send routes for a transport

• Send routes can be added to restrict the address ranges to which outgoing messages can be sent by the transport plugin. Any number of send routes can be added, but these must be done before the participant is enabled.

• To restrict address ranges to which outgoing messages can be sent by the transport plugin: