Using Transport Plugins

Summary: Configuring transports used by dds.

There is more than one way to install a transport plugin for use with dds:

  • If it is a builtin transport plugin, by specifying a bitmask in DDS.TransportBuiltinQosPolicy (see NDDS_TransportBuiltinsComponent)
  • For all other non-builtin transport plugins, by dynamically loading the plugin through DDSPropertyQosModule QoS policy settings of DDS.DomainParticipant (on UNIX, Solaris and Windows systems only) (see NDDSTransportLoadPluginModule) The lifecycle of the transport plugin is automatically managed by dds. See NDDSTransportModule_lifecycle for details.

    Loading Transport Plugins through Property QoS Policy of Domain Participant

    On UNIX, Solaris and Windows operating systems, a non-builtin transport plugin written in C/C++ and built as a dynamic-link library (*.dll/*.so) can be loaded by RTI Connext through the DDSPropertyQosModule QoS policy settings of the DDS.DomainParticipant. The dynamic-link library (and all the dependent libraries) need to be in the path during runtime (in LD_LIBRARY_PATH environment variable on Linux/Solaris systems,and in PATH environment variable for Windows systems).

    To allow dynamic loading of the transport plugin, the transport plugin must implement the RTI Connext abstract transport API and must provide a function with the signature NDDS_Transport_create_plugin that can be called by RTI Connext to create an instance of the transport plugin. The name of the dynamic library that contains the transport plugin implementation, the name of the function and properties that can be used to create the plugin, and the aliases and network address that are used to register the plugin can all be specified through the DDSPropertyQosModule QoS policy of the DDS.DomainParticipant.

    The following table lists the property names that are used to load the transport plugins dynamically:

    Properties for dynamically loading and registering transport plugins
    Property Name Description Required?
    dds.transport.load_plugins Comma-separated strings indicating the prefix names of all plugins that will be loaded by dds. Up to 8 plugins may be specified. For example, "dds.transport.WAN.wan1, dds.transport.DTLS.dtls1",
    In the following examples, ransport_prefix is used to indicate one element of this string that is used as a prefix in the property names for all the settings that are related to the plugin. ransport_prefix must begin with "dds.transport." (such as "dds.transport.mytransport").     		YES
    ransport_prefix.library Should be set to the name of the dynamic library (*.so for Unix/Solaris, and *.dll for Windows) that contains the transport plugin implementation. This library (and all the other dependent dynamic libraries) needs to be in the path during run time for used by RTI Connext (in the LD_LIBRARY_PATH environment variable on UNIX/Solaris systems, in PATH for Windows systems). YES
    ransport_prefix.create_function Should be set to the name of the function with the prototype of NDDS_Transport_create_plugin that can be called by RTI Connext to create an instance of the plugin. The resulting transport plugin will then be registered by RTI Connext through NDDSTransportSupport.register_transport YES
    ransport_prefix.aliases Used to register the transport plugin returned by NDDS_Transport_create_plugin (as specified by ransport_prefix.create_function) to the DDS.DomainParticipant. Refer to aliases_in parameter in NDDSTransportSupport.register_transport for details. Aliases should be specified as a comma-separated string, with each comma delimiting an alias. If it is not specified, ransport_prefix --without the leading "dds.transport" -- is used as the default alias for the plugin. NO
    ransport_prefix.network_address Used to register the transport plugin returned by NDDS_Transport_create_plugin (as specified by ransport_prefix.create_function) to the DDS.DomainParticipant. Refer to network_address_in parameter in NDDSTransportSupport.register_transport for details. If it is not specified, the network_address_out output parameter from NDDS_Transport_create_plugin is used. The default value is a zeroed out network address. NO
    ransport_prefix.<property_name> Property that is passed into NDDS_Transport_create_plugin (as specified by ransport_prefix.create_function) for creating the transport plugin. This property name-value pair will be passed to NDDS_Transport_create_plugin after stripping out ransport_prefix from the property name. The parsing of this property and configuring the transport using this property should be handled by the implementation of each transport plugin. Multiple ransport_prefix.<property_name> can be specified.

    Note: "library", "create_function", "aliases" and "network_address" cannot be used as the <property_name> due to conflicts with other builtin property names.

    		NO

    A transport plugin is dynamically created and registered to the DDS.DomainParticipant by RTI Connext when:

  • the DDS.DomainParticipant is enabled,
  • the first DataWriter/DataReader is created, or
  • you lookup a builtin DataReader (DDS.Subscriber.lookup_datareader),

    whichever happens first.

    Any changes to the transport plugin related properties in DDSPropertyQosModule QoS policy after the transport plugin has been registered with the DDS.DomainParticipant will have no effect.