Ports Used for Discovery

There are two kinds of traffic in a Connext DDS application: discovery (meta) traffic, and user traffic. Meta-traffic is for data (declarations) that is sent between the automatically-created discovery writers and readers; user traffic is for data that is sent between user-created DataWriters and DataReaders. To keep the two kinds of traffic separate, Connext DDS uses different ports, as described below.

Note: The ports described in this section are used for incoming data. Connext DDS uses ephemeral ports for outbound data.

Connext DDS uses the RTPS wire protocol. The discovery protocols defined by RTPS rely on well-known ports to initiate discovery. These well-known ports define the multicast and unicast ports on which a Participant will listen for meta-traffic from other Participants. The meta-traffic contains the information required by Connext DDS to establish the presence of remote Entities in the network.

The well-known incoming ports 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 DDS. These parameters are shown in WireProtocol QosPolicy’s rtps_well_known_ports (DDS_RtpsWellKnownPorts_t). (For defaults and valid ranges, please see the API Reference HTML documentation.)

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 Tuning domain_id_gain and participant_id_gain.

participant_id_gain

builtin_multicast_port_offset

Additional offset for meta-traffic port. See Inbound Ports for Meta-Traffic.

builtin_unicast_port_offset

user_multicast_port_offset

Additional offset for user traffic port. See 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 WireProtocol QosPolicy’s rtps_well_known_ports (DDS_RtpsWellKnownPorts_t), the port formulas described below depend on:

Backwards Compatibility: Connext DDS 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].

© 2018 RTI