RTI Connext .NET API (legacy)
Version 6.1.0
|
RTPS well-known port mapping configuration. More...
#include <managed_infrastructure.h>
Public Attributes | |
System::Int32 | port_base |
The base port offset. More... | |
System::Int32 | domain_id_gain |
Tunable domain gain parameter. More... | |
System::Int32 | participant_id_gain |
Tunable participant gain parameter. More... | |
System::Int32 | builtin_multicast_port_offset |
Additional offset for metatraffic multicast port. More... | |
System::Int32 | builtin_unicast_port_offset |
Additional offset for metatraffic unicast port. More... | |
System::Int32 | user_multicast_port_offset |
Additional offset for usertraffic multicast port. More... | |
System::Int32 | user_unicast_port_offset |
Additional offset for usertraffic unicast port. More... | |
Properties | |
static RtpsWellKnownPorts_t | RTI_BACKWARDS_COMPATIBLE_RTPS_WELL_KNOWN_PORTS [get] |
Assign to use well-known port mappings which are compatible with previous versions of the RTI Connext middleware. More... | |
static RtpsWellKnownPorts_t | INTEROPERABLE_RTPS_WELL_KNOWN_PORTS [get] |
Assign to use well-known port mappings which are compliant with OMG's DDS Interoperability Wire Protocol. More... | |
RTPS well-known port mapping configuration.
RTI Connext 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 discovery metatraffic from other Participants. The discovery metatraffic contains all the information required to establish the presence of remote DDS entities in the network.
The well-known ports are defined by RTPS in terms of port mapping expressions with several tunable parameters, which allow you to customize what network ports are used by RTI Connext. These parameters are exposed in DDS::RtpsWellKnownPorts_t. 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.
The actual port mapping expressions, as defined by the RTPS specification, can be found below. In addition to the parameters listed in DDS::RtpsWellKnownPorts_t, the port numbers depend on:
- domain_id
, as specified in DDS::DomainParticipantFactory::create_participant
- participant_id
, as specified using DDS::WireProtocolQosPolicy::participant_id
The domain_id
parameter ensures no port conflicts exist between Participants belonging to different domains. This also means that discovery metatraffic in one domain is not visible to Participants in a different domain. The participant_id
parameter ensures that unique unicast port numbers are assigned to Participants belonging to the same domain on a given host.
The metatraffic_unicast_port is used to exchange discovery metatraffic using unicast.
metatraffic_unicast_port = port_base + (domain_id_gain * domain_id) + (participant_id_gain * participant_id) + builtin_unicast_port_offset
The metatraffic_multicast_port is used to exchange discovery metatraffic using multicast. The corresponding multicast group addresses are specified via DDS::DiscoveryQosPolicy::multicast_receive_addresses on a DDS::DomainParticipant entity.
metatraffic_multicast_port = port_base + (domain_id_gain * domain_id) + builtin_multicast_port_offset
RTPS also defines the default multicast and unicast ports on which DataReaders and DataWriters receive usertraffic. These default ports can be overridden using the DDS::DataReaderQos::multicast, DDS::DataReaderQos::unicast, or by the DDS::DataWriterQos::unicast QoS policies.
The usertraffic_unicast_port is used to exchange user data using unicast.
usertraffic_unicast_port = port_base + (domain_id_gain * domain_id) + (participant_id_gain * participant_id) + user_unicast_port_offset
The usertraffic_multicast_port is used to exchange user data using multicast. The corresponding multicast group addresses can be configured using DDS::TransportMulticastQosPolicy.
usertraffic_multicast_port = port_base + (domain_id_gain * domain_id) + user_multicast_port_offset
By default, the port mapping parameters are configured to compliant with OMG's DDS Interoperability Wire Protocol (see also DDS::RtpsWellKnownPorts_t::INTEROPERABLE_RTPS_WELL_KNOWN_PORTS).
The OMG's DDS Interoperability Wire Protocol compliant port mapping parameters are not backwards compatible with previous versions of the RTI Connext middleware.
When modifying the port mapping parameters, care must be taken to avoid port aliasing. This would result in undefined discovery behavior. The chosen parameter values will also determine the maximum possible number of domains in the system and the maximum number of participants per 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].
Note: On Windows, you should avoid using ports 49152 through 65535 for inbound traffic. RTI Connext's ephemeral ports (see "Ports Used for Discovery" in the User's Manual) may be within that range (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms737550(v=vs.85).aspx). With the default RtpsWellKnownPorts settings, port 49152 corresponds to domain ID 167, so using domain IDs 168 through 232 on Windows introduces the risk of a port collision and failure to create the Domain Participant when using multicast discovery. You may see this error:
RTIOsapiSocket_bindWithIP:OS bind() failure, error 0X271D: An attempt was made to access a socket in a way forbidden by its access permissions.
System::Int32 DDS::RtpsWellKnownPorts_t::port_base |
The base port offset.
All mapped well-known ports are offset by this value.
[default] 7400
[range] [>= 1], but resulting ports must be within the range imposed by the underlying transport.
System::Int32 DDS::RtpsWellKnownPorts_t::domain_id_gain |
Tunable domain gain parameter.
Multiplier of the domain_id
. Together with participant_id_gain
, it determines the highest domain_id
and participant_id
allowed on this network.
In general, there are two ways to setup domain_id_gain
and participant_id_gain
parameters.
If domain_id_gain
> participant_id_gain
, it results in a port mapping layout where all DDS::DomainParticipant instances within a single domain occupy a consecutive range of domain_id_gain
ports. Precisely, all ports occupied by the domain fall within:
(port_base + (domain_id_gain * domain_id))
and:
(port_base + (domain_id_gain * (domain_id + 1)) - 1)
Under such a case, the highest domain_id
is limited only by the underlying transport's maximum port. The highest participant_id
, however, must satisfy:
max_participant_id < (domain_id_gain / participant_id_gain)
On the contrary, if domain_id_gain
<= participant_id_gain
, it results in a port mapping layout where a given domain's DDS::DomainParticipant instances occupy ports spanned across the entire valid port range allowed by the underlying transport. For instance, it results in the following potential mapping:
Mapped Port | Domain Id | Participant ID |
higher port number | Domain Id = 1 | Participant ID = 2 |
Domain Id = 0 | Participant ID = 2 | |
Domain Id = 1 | Participant ID = 1 | |
Domain Id = 0 | Participant ID = 1 | |
Domain Id = 1 | Participant ID = 0 | |
lower port number | Domain Id = 0 | Participant ID = 0 |
Under this case, the highest participant_id
is limited only by the underlying transport's maximum port. The highest domain_id
, however, must satisfy:
max_domain_id < (participant_id_gain / domain_id_gain)
Additionally, domain_id_gain
also determines the range of the port-specific offsets.
domain_id_gain > abs(builtin_multicast_port_offset - user_multicast_port_offset)
domain_id_gain > abs(builtin_unicast_port_offset - user_unicast_port_offset)
Violating this may result in port aliasing and undefined discovery behavior.
[default] 250
[range] [> 0], but resulting ports must be within the range imposed by the underlying transport.
System::Int32 DDS::RtpsWellKnownPorts_t::participant_id_gain |
Tunable participant gain parameter.
Multiplier of the participant_id
. See DDS::RtpsWellKnownPorts_t::domain_id_gain for its implications on the highest domain_id
and participant_id
allowed on this network.
Additionally, participant_id_gain
also determines the range of builtin_unicast_port_offset
and user_unicast_port_offset
.
participant_id_gain > abs(builtin_unicast_port_offset - user_unicast_port_offset)
[default] 2
[range] [> 0], but resulting ports must be within the range imposed by the underlying transport.
System::Int32 DDS::RtpsWellKnownPorts_t::builtin_multicast_port_offset |
Additional offset for metatraffic multicast port.
It must be unique from other port-specific offsets.
[default] 0
[range] [>= 0], but resulting ports must be within the range imposed by the underlying transport.
System::Int32 DDS::RtpsWellKnownPorts_t::builtin_unicast_port_offset |
Additional offset for metatraffic unicast port.
It must be unique from other port-specific offsets.
[default] 10
[range] [>= 0], but resulting ports must be within the range imposed by the underlying transport.
System::Int32 DDS::RtpsWellKnownPorts_t::user_multicast_port_offset |
Additional offset for usertraffic multicast port.
It must be unique from other port-specific offsets.
[default] 1
[range] [>= 0], but resulting ports must be within the range imposed by the underlying transport.
System::Int32 DDS::RtpsWellKnownPorts_t::user_unicast_port_offset |
Additional offset for usertraffic unicast port.
It must be unique from other port-specific offsets.
[default] 11
[range] [>= 0], but resulting ports must be within the range imposed by the underlying transport.