Specifies the maximum number of buffers that Connext can pass to the send() method of a transport plugin.

The transport plugin send() API supports a gather-send concept, where the send() call can take several discontiguous buffers, assemble and send them in a single message. This enables Connext to send a message from parts obtained from different sources without first having to copy the parts into a single contiguous buffer.

However, most transports that support a gather-send concept have an upper limit on the number of buffers that can be gathered and sent. Setting this value will prevent Connext from trying to gather too many buffers into a send call for the transport plugin.

Connext requires all transport-plugin implementations to support a gather-send of least a minimum number of buffers. This minimum number is NDDS_TRANSPORT_PROPERTY_GATHER_SEND_BUFFER_COUNT_MIN.

See 51.6.1 Setting the Maximum Gather-Send Buffer Count for UDP Transports.

Default: 16

The maximum size of a message in bytes that can be sent or received by the transport plugin. Above this size, DDS-level fragmentation will occur. See 34.3 Large Data Fragmentation.

This value must be set before the transport plugin is registered, so that Connext can properly use the plugin.

Default for Integrity platforms: 9216

Default for non-Integrity platforms: 65507

A list of strings, each identifying a range of interface addresses or an interface name.

As a property value, interfaces must be specified as comma-separated strings, with each comma delimiting an interface. In XML, they are provided as a set of elements (<element>) under <allow_interfaces_list>. For example, the following are acceptable strings:

192.168.1.1

192.168.1.*

192.168.*

192.*

ether0

If the list is non-empty, this "white" list is applied before the parent.deny_interfaces_list list.

The DomainParticipant will use the resulting list of interfaces to inform its remote participant(s) about which unicast addresses may be used to contact the DomainParticipant.

You must manage the memory of the list. The memory may be freed after the DomainParticipant is deleted.

The left-to-right order of this list matters if you are using the max_interface_count to limit the allowable interfaces further. See max_interface_count.

Default: empty list that represents all available interfaces

A list of strings, each identifying a range of interface addresses or an interface name. If the list is non-empty, deny the use of these interfaces.

As a property value, interfaces must be specified as comma-separated strings, with each comma delimiting an interface. In XML, they are provided as a set of elements (<element>) under <deny_interfaces_list>. For example, the following are acceptable strings:

192.168.1.1

192.168.1.*

192.168.*

192.*

ether0

This "black" list is applied after the parent.allow_interfaces_list and filters out the interfaces that should not be used for receiving data. The resulting list restricts reception to a particular set of interfaces for unicast UDP.

You must manage the memory of the list. The memory may be freed after the DomainParticipant is deleted.

Default: empty list that represents no deny interfaces

How many of the addresses in your allowed interfaces list are used, at most, at any time.

This feature is useful if you want to control the network interfaces on which your DomainParticipants receive data. For example, if you have one wired and one wireless interface in your allowed interfaces list both up and running, and max_interface_count is set to 1, the DomainParticipant will receive data over the interface you list first in the allow_interfaces_list—for example, the wired one. If the wired interface is not in use (for example, the device is undocked), then the DomainParticipant will receive data only over the next available up-and-running interface in your allow_interfaces_list, which would be the wireless one.

Connext selects the preferred interface(s) by iterating over the list of allowed interfaces until the first max_interfaces_count of active interfaces encountered are announced. The order of iteration is left to right as specified in the allow_interfaces_list setting.

This setting applies only if the allow_interfaces_list is not empty.

The max_interface_count setting does not consider end-to-end connectivity to select interfaces. The decision is based purely on whether interfaces are up or down in a node. Therefore, this feature is not intended to be used in the following scenarios:

• A DomainParticipant is not reachable by other DomainParticipants in all the interfaces in the allow_interfaces_list. This could occur if the DomainParticipant is in different subnets, and some of these subnets cannot be reached by other DomainParticipants.
• End-to-end connectivity issues lead to situations in which the interfaces selected after applying max_interface_count cannot be reached by other DomainParticipants.

Note: If a pattern string in the allow_interfaces_list matches multiple interface addresses, and max_interface_count is set to a finite value, the order for the matching allowed interfaces is decided based on the order in which the operating system provides these interfaces.

Default: LENGTH_UNLIMITED

Range: [1, LENGTH_UNLIMITED]

A bitmap that defines various properties of the transport to the Connext core. Currently, the only property supported is whether or not the transport plugin will always loan a buffer when Connext tries to receive a message using the plugin. This is in support of a zero-copy interface.

Default: 0

By default, property names given in the 47.19 PROPERTY QosPolicy (DDS Extension) are validated to avoid using incorrect or unknown names (for example, due to a typo). This property configures the validation of the property names associated with the transport:

• VALIDATION_ACTION_EXCEPTION: validate the properties. Upon failure, log errors and fail.
• VALIDATION_ACTION_SKIP: skip validation.
• VALIDATION_ACTION_WARNING: validate the properties. Upon failure, log warnings and do not fail.

If this property is not set, the property validation behavior will be the same as that of the DomainParticipant, which by default is VALIDATION_ACTION_EXCEPTION. See 47.19.1 Property Validation for more information.

If you do not set this field, Connext creates the following prefix:

Where 'r' indicates this is a thread from RTI, 'Tr' indicates the thread is related to a transport, and participant identifier contains 5 characters as follows:

• If participant_name is set: The participant identifier will be the first 3 characters and the last 2 characters of the participant_name.
• If participant_name is not set, then the identifier is computed as domain_id (3 characters) followed by participant_id (2 characters).
• If participant_name is not set and the participant_id is set to -1 (default value), then the participant identifier is computed as the last 5 digits of the rtps_instance_id in the participant GUID.

See Chapter 73 Identifying Threads Used by Connext.

Maximum size in bytes of protocol overhead, including headers.

This value is the maximum size, in bytes, of protocol-related overhead. Normally, the overhead accounts for UDP and IP headers. The default value is set to accommodate the most common UDP/IP header size.

Note that when parent.message_size_max plus this overhead is larger than the UDPv4 maximum message size (65535 bytes), the middleware will automatically reduce the effective message_size_max to 65535 minus this overhead.

Default: 28

Size in bytes of the send buffer of a socket used for sending. On most operating systems, setsockopt() will be called to set the SENDBUF to the value of this parameter.

This value must be greater than or equal to parent.message_size_max. The maximum value is operating system-dependent.

If -1, setsockopt() (or equivalent) will not be called to size the send buffer of the socket. The transport will use the OS default.

Default: 131072

Size in bytes of the receive buffer of a socket used for receiving. On most operating systems, setsockopt() will be called to set the RECVBUF to the value of this parameter.

This value must be greater than or equal to parent.message_size_max. The maximum value is operating system-dependent.

If -1, setsockopt() (or equivalent) will not be called to size the receive buffer of the socket. The transport will use the OS default.

Default: 131072

Prevents the transport plugin from using the IP loopback interface. Three values are allowed:

• 0: Forces local traffic to be sent over loopback, even if a more efficient transport (such as shared memory) is installed (in which case traffic will be sent over both transports).
• 1: Disables local traffic via this plugin. The IP loopback interface will not be used, even if no NICs are discovered. This is useful when you want applications running on the same node to use a more efficient transport (such as shared memory) instead of the IP loopback.
• -1: Automatic. Enables local traffic via this plugin. To avoid redundant traffic, Connext will selectively ignore the loopback destinations that are also reachable through shared memory.

Default: -1

This property is only supported on Windows platforms with statically configured IP addresses.

It allows/disallows the use of interfaces that are not reported as UP (by the operating system) in the UDPv4_WAN transport. Two values are allowed:

• 0: Allow interfaces that are reported as DOWN.
  • Setting this value to 0 supports communication scenarios in which interfaces are enabled after the participant is created. Once the interfaces are enabled, discovery will not occur until the participant sends the next periodic announcement (controlled by the parameter participant_qos.discovery_config.participant_liveliness_assert_period).
  • To reduce discovery time, you may want to decrease the value of participant_liveliness_assert_period. For the above scenario, there is one caveat: non-UP interfaces must have a static IP assigned.
• 1: Do not allow interfaces that are reported as DOWN.

Default:1

Prevents the transport plugin from using a network interface that is not reported as RUNNING by the operating system.

The transport checks the flags reported by the operating system for each network interface upon initialization. An interface which is not reported as UP will not be used. This property allows the same check to be extended to the IFF_RUNNING flag implemented by some operating systems. The RUNNING flag is defined to mean that "all resources are allocated", and may be off if there is no link detected, e.g., the network cable is unplugged. Two values are allowed:

• 0: Do not check the RUNNING flag when enumerating interfaces, just make sure the interface is UP.
• 1: Check the flag when enumerating interfaces, and ignore those that are not reported as RUNNING. This can be used on some operating systems to cause the transport to ignore interfaces that are enabled but not connected to the network.

By default this property is set to 1, so Connext will ignore non-running interfaces.

Prevents the transport plugin from doing a zero copy.

By default, this plugin will use the zero copy on OSs that offer it. While this is good for performance, it may sometimes tax the OS resources in a manner that cannot be overcome by the application.

The best example is if the hardware/device driver lends the buffer to the application itself. If the application does not return the loaned buffers soon enough, the node may error or malfunction. In case you cannot reconfigure the hardware, device driver, or the OS to allow the zero-copy feature to work for your application, you may have no choice but to turn off zero-copy.

By default this is set to 0, so Connext will use the zero-copy API if offered by the OS.

Controls the blocking behavior of send sockets. CHANGING THIS FROM THE DEFAULT CAN CAUSE SIGNIFICANT PERFORMANCE PROBLEMS. Currently two values are defined:

• 1 (NDDS_TRANSPORT_UDP_BLOCKING_ALWAYS): Sockets are blocking (default socket options for operating system).
• 0 (NDDS_TRANSPORT_UDP_BLOCKING_NEVER): Sockets are modified to make them non-blocking. This may cause significant performance problems.

Default: 1

Sets the mask for the transport priority field. This is used in conjunction with transport_priority_mapping_low and transport_priority_mapping_high to define the mapping from the 47.26 TRANSPORT_PRIORITY QosPolicy to the IPv4 TOS field. Defines a contiguous region of bits in the 32-bit transport priority value that is used to generate values for the IPv4 TOS field on an outgoing socket.

For example, the value 0x0000ff00 causes bits 9-16 (8 bits) to be used in the mapping. The value will be scaled from the mask range (0x0000 - 0xff00 in this case) to the range specified by low and high.

If the mask is set to zero, then the transport will not set IPv4 TOS for send sockets.

Default: 0

Sets the low and high values of the output range to IPv4 TOS.

These values are used in conjunction with transport_priority_mask to define the mapping from the 47.26 TRANSPORT_PRIORITY QosPolicy to the IPv4 TOS field. Defines the low and high values of the output range for scaling.

Note that IPv4 TOS is generally an 8-bit value.

Default: 0 for transport_priority_mapping_low and 0xFF for transport_priority_mapping_high

This property specifies whether to send a PING message before commencing the discovery process. On certain operating systems or with certain switches the initial UDP packet, configuring the ARP table, was unfortunately dropped. To avoid dropping the initial RTPS discovery sample, a PING message is sent to preconfigure the ARP table in those environments.

Default: 1

This property specifies whether the UDP checksum will be computed. On Windows and Linux systems, the UDP checksum will not be set when use_checksum is set to 0. This is useful when RTPS protocol statistics related to corrupted messages need to be collected through the operation get_participant_protocol_status() (see 16.3.14 Getting Participant Protocol Status ).

Default: 1

Specifies the period in milliseconds to query for changes in the state of all the interfaces.

When possible, the detection of an IP address changes is done asynchronously using the APIs offered by the underlying OS. If there is no mechanism to do that, the detection will use a polling strategy where the polling period can be configured by setting this property.

Default: 500

This property forces the interface tracker to use a polling method to detect changes to the network interfaces in IP mobility scenarios. It only applies to operating systems that support asynchronous notifications of interface changes.

If set to TRUE, the interface tracker will use a polling method that queries the interfaces periodically to detect the changes. If set to FALSE, the interface tracker will use the operating system’s default method.

Basically, this property allows you—for an operating system that supports asynchronous notification—to use the polling method instead.

Default: FALSE

Disables detection of network interface changes.

By default, network interfaces changes are propagated in the form of locators to other applications. This is done to support IP mobility scenarios. For example, you could start an application with Wi-Fi and move to a wired connection. In order to continue communicating with other applications, this interface change must be propagated.

You can disable the notification and propagation of interface changes by setting this property to 1.

Public IP address associated with the transport instantiation. The address is the public IP address of the NAT-enabled router that provides access to the WAN.

Setting the public IP address is only necessary for the Real-Time WAN Transport associated with an external DomainParticipant in order to support the communication scenario described in 52.4.1 Peer-to-Peer Communication between Internal Participant and External Participant.

When this property is set, the DomainParticipant will announce PUBLIC+UUID locators to other DomainParticipants. These locators are reachable locators because they contain a public IP transport address for the DomainParticipant. For additional information on Real-Time WAN Transport locators, see 52.10.1 Transport Locators.

By default, the public address is not set.

Configures the period in milliseconds at which BINDING_PING messages are sent by a local transport instance to a remote transport instance. For example, 1000 means to send BINDING_PING messages every second.

BINDING_PING messages are used on the sending side to open NAT bindings from a local transport instance to a remote transport instance and they are sent periodically to keep the bindings open.

For additional information on the role of BINDING_PING messages opening NAT bindings, see 52.10.3 Communication Establishment Protocol for Peer-to-Peer Communication with Participants behind Cone NATs.

On the receiving side, BINDING_PINGS are used to calculate the public IP transport address of a UUID locator. This address will be used to send data to the locator.

For additional information on the role of BINDING_PING to associate UUID locators to public IP transport addresses, see 52.10.4 Communication Establishment Protocol for Peer-to-Peer Communication with a Participant that has a Public Address.

From a configuration point of view, and to avoid communication disruptions, the period at which a transport instance sends BINDING_PING messages should be smaller than the NAT binding session timeout. This timeout depends on the NAT router configuration.

Default: 1000 (1 sec)

This property allows using the builtin UDPv4 transport and the Real-Time WAN Transport at the same time.

<transport_builtin>
    <mask>UDPv4_WAN|UDPv4</mask>
</transport_builtin>

When the UDP ports used by Real-Time WAN Transport are not explicitly set, they are calculated as follows: RTPS port + port_offset. See 52.8.2 Managing UDP Ports Used for Communication for additional details.

Default: 125

Configures the public and private UDP ports that a transport instance uses to receive/send RTPS data. See 52.8.2 Managing UDP Ports Used for Communication for additional details.

If this property is not set (default), the UDP ports used for communications will be derived from the RTPS ports associated with the locators for the DomainParticipant and its endpoints (DataWriters and DataReaders).