51.10 Instantiating Multiple Instances of UDPv4/UDPv6 Transports

By default, it is not possible to have multiple instances of the UDPv4 or UDPv6 transport in the same DomainParticipant, because all instances will try to bind to the same UDP port(s) for receiving data.

By using the properties dds.transport.UDPv4.builtin.port_offset and dds.transport.UDPv6.builtin.port_offset, however, you can have multiple instances of the UDPv4/UDPv6 transport in the same DomainParticipant if each instance uses different offsets. The offset is added to the RTPS port(s) to determine the UDP port(s) to bind to. This capability is particularly beneficial when Connext applications are operating across various subnets, because it enables more efficient use of network and CPU resources.

An RTPS port is mapped to a UDP port as follows: UDP port = RTPS port + port_offset.

By allowing multiple instances of the UDPv4/UDPv6 transport in a single DomainParticipant, you can assign each one of them to a different subnet. Even though a DomainParticipant will announce the locators from all the subnets as part of the participant announcements, the remote DomainParticipants within subnet 'S1' will not try to use a locator associated with subnet 'S2' to send data to other DomainParticipants in 'S1'. See Figure 51.1: Multiple Instances of a Transport in a DomainParticipant.

Figure 51.1: Multiple Instances of a Transport in a DomainParticipant

For example, assume that a single DomainParticipant 'DP1' has to communicate with DomainParticipants in subnets 'S1' and 'S2'. Subnet 'S1' can be reached using the interface 10.10.1.1, and subnet 'S2' can be reached using the interface 20.10.1.1. To support this communication scenario with minimal overhead using the offset properties, you can configure 'DP1' as follows:

<domain_participant_qos>
    <property>
        <value>
        <!-- The following properties are used to configure a new instance of UDP
        transport to work over the subnet ::2 -->
            <element>
                <name>dds.transport.load_plugins</name>
                <value>dds.transport.UDPv4.udpv4_subnet_2</value>
            </element>
            <element>
                <name>dds.transport.UDPv4.udpv4_subnet_2.aliases</name>
                <value>udpv4_subnet_2</value>
            </element>
            <element>
                <name>dds.transport.UDPv4.udpv4_subnet_2.network_address</name>
                <value>::2</value>
            </element>
            <element>
                <name>dds.transport.UDPv4.udpv4_subnet_2.parent.allow_interfaces_list</name>
                <value>20.10.1.1</value>
            </element>
            <element>
                <name>dds.transport.UDPv4.udpv4_subnet_2.port_offset</name>
                <value>125</value>
            </element>
            <!-- The following properties are used to configure the builtin instance of
            UDP transport to work over the subnet ::1 -->
            <element>
                <name>dds.transport.UDPv4.builtin.parent.allow_interfaces_list</name>
                <value>10.10.1.1</value>
            </element>
            <element>
                <name>dds.transport.UDPv4.builtin.network_address</name>
                <value>::1</value>
            </element>
        </value>
    </property>
    <discovery>
        <initial_peers>
            <element>udpv4_subnet_2://::2#20.10.1.3</element>
            <element>udpv4_builtin://::1#10.10.1.3</element>
        </initial_peers>
    </discovery>
</domain_participant_qos>

Note that in this example, you use the dds.transport.UDPv4.udpv4_subnet_2.network_address and dds.transport.UDPv4.builtin.network_address properties to assign each transport to a different subnet. The value of these properties has to be unique per subnet, but it does not need to correspond to the actual IP subnet. A DomainParticipant will never use the transport on subnet 'S1' to send data to subnet 'S2'.

See 51.6 Setting Builtin Transport Properties with the PropertyQosPolicy for instructions on setting the transport properties.