Working with pluggable transports.
More...
Working with pluggable transports.
Changing the automatically registered built-in transports
Changing the properties of the automatically registered builtin transports
The behavior of the automatically registered builtin transports can be altered by changing their properties.
- 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.
- 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.
- 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: