6.1. Transport API¶
The following diagram presents the classes defined on the transport API of eProsima Fast DDS. It shows the abstract API interfaces, and the classes required to implement a transport.
Transport API diagram¶
6.1.1. TransportDescriptorInterface¶
Any class that implements the TransportDescriptorInterface
is known as a TransportDescriptor
.
It acts as a builder for a given transport, meaning that is allows to configure the transport,
and then a new Transport can be built according to this configuration
using its create_transport()
factory member function.
6.1.1.1. Data members¶
The TransportDescriptorInterface defines the following data members:
Member |
Data type |
Description |
---|---|---|
|
|
Maximum size of a single message in the transport. |
|
|
Number of channels opened with each initial remote peer |
Any implementation of TransportDescriptorInterface should add as many data members as required to full configure the transport it describes.
6.1.2. TransportInterface¶
A Transport
is any class that implements the TransportInterface
.
It is the object that actually performs the message distribution over a physical transport.
Each Transport
class defines its own transport_kind
, a unique identifier that is used to
check the compatibility of a Locator with a Transport, i.e.,
determine whether a Locator refers to a Transport or not.
Applications do not create the Transport
instance themselves.
Instead, applications use a TransportDescriptor
instance to configure the desired transport, and add
this configured instance to the list of user-defined transports of the DomainParticipant.
The DomainParticipant will use the factory function on the TransportDescriptor
to create the Transport
when required.
DomainParticipantQos qos;
// Create a descriptor for the new transport.
auto udp_transport = std::make_shared<UDPv4TransportDescriptor>();
udp_transport->sendBufferSize = 9216;
udp_transport->receiveBufferSize = 9216;
udp_transport->non_blocking_send = true;
// Link the Transport Layer to the Participant.
qos.transport().user_transports.push_back(udp_transport);
// Avoid using the default transport
qos.transport().use_builtin_transports = false;
6.1.2.1. Data members¶
The TransportInterface defines the following data members:
Member |
Data type |
Description |
---|---|---|
|
|
Unique identifier of the transport type. |
Note
transport_kind_
is a protected data member for internal use.
It cannot be accessed nor modified from the public API.
However, users that are implementing a custom Transport need to fill it with a unique constant value
in the new implementation.
Currently the following identifiers are used in Fast DDS:
Identifier |
Value |
Transport type |
---|---|---|
|
|
None. Reserved value for internal use. |
|
|
UDP Transport over IPv4. |
|
|
UDP Transport over IPv6. |
|
|
TCP Transport over IPv4. |
|
|
TCP Transport over IPv6. |
|
|
6.1.3. Locator¶
A Locator_t
uniquely identifies a communication channel with a remote peer for a particular transport.
For example, on UDP transports, the Locator will contain the information of the IP address and port
of the remote peer.
The Locator class is not abstract, and no specializations are implemented for each transport type.
Instead, transports should map the data members of the Locator class to their own channel identification
concepts. For example, on Shared Memory Transport the address
contains a unique ID
for the local host, and the port
represents the shared ring buffer used to communicate buffer descriptors.
Please refer to Listening Locators for more information about how to configure DomainParticipant to listen to incoming traffic.
6.1.3.1. Data members¶
The Locator defines the following data members:
Member |
Data type |
Description |
---|---|---|
|
|
Unique identifier of the transport type. |
|
|
The channel port. |
|
|
The channel address. |
In TCP, the port of the locator is divided into a physical and a logical port.
The physical port is the port used by the network device, the real port that the operating system understands. It is stored in the two least significant bytes of the member
port
.The logical port is the RTPS port. It is stored in the two most significant bytes of the member
port
.
In UDP there is only the physical port, which is also the RTPS port, and is stored in the two least significant bytes
of the member port
.
6.1.3.2. Configuring IP locators with IPLocator¶
IPLocator
is an auxiliary static class that offers methods to manipulate IP based locators.
It is convenient when setting up a new UDP Transport or TCP Transport,
as it simplifies setting IPv4 and IPv6 addresses, or manipulating ports.
For example, normally users configure the physical port and do not need to worry about logical ports.
However, IPLocator
allows to manage them if needed.
// We will configure a TCP locator with IPLocator
Locator_t locator;
// Get & set the physical port
uint16_t physical_port = IPLocator::getPhysicalPort(locator);
IPLocator::setPhysicalPort(locator, 5555);
// On TCP locators, we can get & set the logical port
uint16_t logical_port = IPLocator::getLogicalPort(locator);
IPLocator::setLogicalPort(locator, 7400);
// Set WAN address
IPLocator::setWan(locator, "80.88.75.55");