52.8.2 Managing UDP Ports Used for Communication
52.8.2.1 Receiving Data
By default, Real-Time WAN Transport uses one UDP port per RTPS port to receive data. The UDP port number is calculated as RTPS port + port_offset.
A DomainParticipant uses two RTPS ports, one for discovery and one for user data. Therefore, Real-Time WAN Transport uses two UDP ports out-of-the-box. For information on how the RTPS ports are obtained, see 44.10.2 Ports Used for Discovery.
You can also configure a specific DataWriter and DataReader to receive unicast data in a different RTPS port by configuring the 47.28 TRANSPORT_UNICAST QosPolicy (DDS Extension)). This will also lead to the usage of a different UDP port by Real-Time WAN Transport.
There are two main use cases in which the default mapping from RTPS ports to UDP ports is not suitable:
- The first use case involves the configuration of the External Participant described in 52.4.1 Peer-to-Peer Communication between Internal Participant and External Participant. In this use case, you must be able to select the private and public UDP ports used for communication because you have to create a static NAT binding on the router for the External Participant.
- The second use case involves the use of UDP load balancers. With UDP load balancers, you must be able to configure a single UDP port to handle all data reception because the load balancer would not know how to map different ports to the same DomainParticipant.
For these use cases, Real-Time WAN Transport provides a way to specify the private and public UDP ports that will be used to serve specific RTPS ports.
52.8.2.1.1 Changing the UDP Port Mapping
The <comm_ports> XML tag or the property dds.transport.UDPv4_WAN.builtin.comm_ports can be used to change the mapping of UDP ports to RTPS ports.
You can specify a list of mappings from an RTPS port to a host, and (optionally) a public UDP port. For RTPS ports that are not part of the list, you can provide a default mapping.
When the property dds.transport.UDPv4_WAN.builtin.comm_ports is used instead of XML, the list is a JSON string.
52.8.2.1.2 Configuring the Transport to Use a Single Port for an External Participant behind a NAT
This configuration will be needed for the External Participant behind a NAT in the scenario described in 52.4.2 Peer-to-Peer Communication between Two Internal Participants.
Figure 52.13: Single Port External Participant
XML:
<udpv4_wan>
<comm_ports>
<default>
<host>1234</host>
<public>2345</public>
</default>
</comm_ports>
</udpv4_wan>
Property dds.transport.UDPv4_WAN.builtin.comm_ports:
{ "default": {"host": 1234,
"public": 2345
}
}
52.8.2.2 Configuring the Transport to Use a Single Port for an Internal Participant behind a NAT
For the Internal Participants behind NATs used in the scenarios described in 52.4 Communication Scenarios, it is not necessary to configure the public port. The public port will be automatically assigned by the NAT once packages are sent from the private address.
Figure 52.14: Single Port Internal Participant
XML:
<udpv4_wan>
<comm_ports>
<default>
<host>1234</host>
</default>
</comm_ports>
</udpv4_wan>
Property dds.transport.UDPv4_WAN.builtin.comm_ports:
{ "default": {"host": 1234,
}
}
52.8.2.3 Configuring the Transport to Segregate Traffic for a Topic in its own Port
In some cases, you may want to segregate the RTPS traffic for a Topic, such as a Video Topic, in its own port. This Topic will get its own socket and receive a socket buffer. It will also get its own receive thread, which will make data reception on the Topic completely concurrent. For details on the middleware threads, see Part 11: Connext Threading Model.
Figure 52.15: Traffic Segregation in Different Port
52.8.2.3.1 External Participant Configuration
<dds>
<qos_profile name="ExternalParticipant">
<domain_participant_qos>
<transport_builtin>
<mask>UDPv4_WAN</mask>
<udpv4_wan>
<public_address>50.10.23.45</public_address>
<comm_ports>
<default>
<host>1234</host>
<public>2345</public>
</default>
<mappings>
<element>
<rtps>5001</rtps>
<host>5000</host>
<public>3456</public>
</element>
</mappings>
</comm_ports>
</udpv4_wan>
</transport_builtin>
</domain_participant_qos>
</qos_profile>
<qos_profile name="VideoTopic" base_name="ExternalParticipant">
<datareader_qos>
<unicast>
<value>
<element>
<receive_port>5001</receive_port>
<transports>
<element>udpv4_wan</element>
</transports>
</element>
</value>
</unicast>
</datareader_qos>
</qos_profile>
</dds>
To use a different port for the Video Topic, you will have to first change the 47.28 TRANSPORT_UNICAST QosPolicy (DDS Extension) to specify an RTPS port (<unicast>/<receiver_port>) for video data reception. Then, you will have to configure the mapping to UDP ports by updating the comm_ports configuration.
If you choose to configure the comm_ports using the property dds.transport.UDPv4_WAN.builtin.comm_ports, the following example will be the JSON string for the scenario described in Figure 52.15: Traffic Segregation in Different Port
{ "default": {"host": 1234,
"Public": 2345
}
"mappings":
[
{"rtps": 5001,
"Host": 5000,
"Public": 3456
}
]
}
52.8.2.4 Sending Data
Data is always sent from a single UDP port. There is no way to send data using different UDP ports for different Topics.
The UDP port used for sending data corresponds to the port associated with the discovery RTPS port according to the rules described in 52.8.2.1 Receiving Data. When the <comms_port>/<default> is defined, the port used for sending data is the one provided in <comms_port>/<default>.