What network port numbers does RTI Connext use?

Note: The ports used are different between RTI Connext 4.x and NDDS 3.x.

RTI Connext

The built-in UDP transport in RTI Connext 4.x and above uses port numbers that are based on the domain ID and participant ID. Because the RTPS spec changed, the mapping is different before and after Version 4.2 of our middleware.

By default, 4.2 and later uses the new, standard RTPS ports. However this is configurable by setting domain_participant_qos.wire_protocol.rtps_well_known_ports to either:

• DDS_RTI_BACKWARDS_COMPATIBLE_RTPS_WELL_KNOWN_PORTS
• or DDS_INTEROPERABLE_RTPS_WELL_KNOWN_PORTS

With DDS_RTI_BACKWARDS_COMPATIBLE_RTPS_WELL_KNOWN_PORTS

• discovery multicast:  7400 + (10 * Domain) + 2
• user multicast: 7400 + (10 * Domain) + 1
• discovery unicast: 7400 + (10 * Domain) + (1000 * Participant) + 0
• user unicast: 7400 + (10 * Domain) + (1000 * Participant) + 3

With DDS_INTEROPERABLE_RTPS_WELL_KNOWN_PORTS

• discovery multicast:   7400 + (250 * Domain) + 0
• user multicast: 7400 + (250 * Domain) + 1
• discovery unicast: 7400 + (250 * Domain) + (2 * Participant) + 10
• user unicast: 7400 + (250 * Domain) + (2 * Participant) + 11

A DataWriter/DataReader (including a built-in DataWriter/DataReader) may specify its own locator, in which case it will get its own port. The QoS to specify its own port is in DataReaderQos.unicast.value, which is a sequence of DDS_TransportUnicastSettings_t. Part of this data structure is the receive_port field, where you can specify the receive port.

The function is an arithmetic formula with 2 input variables; it is NOT reversible. With version 4.1, there are limits on the allowed domain ID (0 to 99, inclusive) and participant_index (0 to 50, inclusive) so that no port collision will occur when you use the default locator. The same is not guaranteed if a DataWriter/DataReader's locator is overridden through the QoS. With version 4.2, there is no inherent limit on the number of domains, although it will be constrained by the available ports in your system.

Note that this function may change in a future version of RTI Connext.

The RTI Connext Core Libraries and Utilities User's Manual also describes port mapping (see Chapter 14, Discovery).

If Secure WAN or DTLS transport is used

An offset, dds.transport.WAN.wan1.port_offset or  dds.transport.DTLS.dtls1.port_offset is introduced to allow the coexistence of WAN and non-WAN UDP transport or DTLS and non-DTLS UDP transport. The value of port_offset is, by default, 144 which is chosen to avoid conflict between port numbers used in consecutive domains. The new port number will be the summation of this offset and the port number calculated by either one of the above algorithms.

NDDS 3.x

The ports used by NDDS 3.x are generated using the algorithm:

7400 + (10 * Domain) + (0 | 1 | 2)

Where:

• 0 is used for the NDDS manager's port (handles both unicast and multicast).
• 1 is for an application's user data multicast port.
• 2 is for an application's discovery data multicast port.

If the application does not use multicast, the multicast port is not opened, so the ports at offsets 1 or 2 may not be used. Note that the well known port numbers are a reversible function of the domain ID.

Please note that "ephemeral ports"—port numbers generated by the operating system—are also used by the publication and subscription threads. Solaris and modern Linux kernels default to port numbers above 32768 for ephemeral ports. The Windows operating system uses higher port numbers (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms737550(v=vs.85).aspx).

For more information about ephemeral ports, please refer to:http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html