Chapter 23 Ports Used for Communication

DDS endpoints (DataWriters and DataReaders) can be reached at specific transport addresses called RTPS locators. An RTPS locator is an n-tuple (transport, address, RTPS port). How an RTPS port is used by a transport depends on the transport. For example, in UDPv4, an RTPS port maps directly to a UDP port 1-to-1. Locator information is sent as part of the Participant and Endpoint DATA messages, which are exchanged during the participant and endpoint discovery phases (see Chapter 22 Discovery Overview).

There are two different uses of the RTPS locators: locators that are used to exchange meta-traffic (during the Participant and Endpoint discovery phases, along with all other traffic from builtin endpoints) and locators that are used to exchange user traffic between user DataWriters and DataReaders. To keep the two kinds of traffic separate, Connext uses different RTPS ports for the two different uses of locators.

The simple participant discovery protocol (SPDP) defined by RTPS relies on well-known ports to initiate discovery. These well-known ports define the multicast and unicast ports on which a Participant will listen for discovery traffic from other Participants. The discovery traffic contains the information required by Connext to establish the presence of remote Entities in the network. There are also well-known ports that are used for user data.

Both the well-known ports for meta-traffic and the well-known ports for user data are defined by RTPS in terms of port mapping expressions with several tunable parameters. This allows you to customize what network ports are used for receiving data by Connext. These parameters are shown in Table 23.1 WireProtocol QosPolicy’s rtps_well_known_ports (DDS_RtpsWellKnownPorts_t). (For defaults and valid ranges, please see the API Reference HTML documentation.)

Table 23.1 WireProtocol QosPolicy’s rtps_well_known_ports (DDS_RtpsWellKnownPorts_t)

Type	Field Name	Description
DDS_Long	port_base	The base port offset. All mapped well-known ports are offset by this value. Resulting ports must be within the range imposed by the underlying transport.
	domain_id_gain	Tunable gain parameters. See 23.4 Tuning domain_id_gain and participant_id_gain.
	participant_id_gain
	builtin_multicast_port_offset	Additional offset for meta-traffic port. See 23.1 Inbound Ports for Meta-Traffic.
	builtin_unicast_port_offset
	user_multicast_port_offset	Additional offset for user traffic port. See 23.2 Inbound Ports for User Traffic.
	user_unicast_port_offset

In order for all Participants in a system to correctly discover each other, it is important that they all use the same port mapping expressions.

In addition to the parameters listed in Table 23.1 WireProtocol QosPolicy’s rtps_well_known_ports (DDS_RtpsWellKnownPorts_t), the port formulas described below depend on:

• The domain ID specified when the DomainParticipant is created (see 16.3.1 Creating a DomainParticipant). The domain ID ensures no port conflicts exist between Participants belonging to different domains. This also means that discovery traffic in one DDS domain is not visible to DomainParticipants in other DDS domains.
• The participant_id is a field in the 44.10 WIRE_PROTOCOL QosPolicy (DDS Extension), see 44.10.1 Choosing Participant IDs. The participant_id ensures that unique unicast port numbers are assigned to DomainParticipants belonging to the same DDS domain on a given host.

Backwards Compatibility: Connext supports the standard DDS Interoperability Wire Protocol based on the Real-time Publish-Subscribe (RTPS) protocol. This protocol is not compatible with the one used by earlier releases (4.2c or lower). Therefore, applications built with 4.2d or higher will not interoperate with applications built with 4.2c or lower. The default port mapping from domainID and participant index has also been changed according to the new interoperability specification. The message types and formats used by RTPS have also changed.

Port Aliasing: When modifying the port mapping parameters, avoid port aliasing. This would result in undefined discovery behavior. The chosen parameter values will also determine the maximum possible number of DDS domains in the system and the maximum number of participants per DDS domain. Additionally, any resulting mapped port number must be within the range imposed by the underlying transport. For example, for UDPv4, this range typically equals [1024 - 65535].