4.7.1. Introduction

In RTI Connext Micro, DDS entities exchange information using transports. Transports exhange data with peer transports, and Connext Micro entities can generally exchange information using different types of transports, e.g. UDPv4 or a serial port. All transports send and receive RTPS messages encapsulated in the transport’s native format, e.g. UDP packets.

Note

This version of Connext Micro only supports UDPv4 and a special transport for internal communication within a DDS DomainParticipant.

Connext Micro has a pluggable-transport architecture. The core of Connext Micro is transport agnostic; it does not make any assumptions about the actual transports used to send and receive messages. Instead, Connext Micro uses an abstract “transport API” to interact with the transport plugins that implement that API. A transport plugin implements the abstract transport API, and performs the actual work of sending and receiving messages over a physical transport.

A transport can send and receive on addresses as defined by the concrete transport. For example, the Connext Micro UDP transport can listen to and send to UDPv4 ports and addresses. In order to establish communication between two transports, the addresses that the transport can listen to must be determined and announced to other DomainParticipants that want to communicate with it. This section describes how the addresses are reserved and how these addresses are used by the DDS layer in Connext Micro.

While the NETIO interface is not limited to DDS, the rest of this document is written in the context of how Connext Micro uses the NETIO interfaces as part of the DDS implementation.

Note that Connext Micro does not support RTPS fragmentation and is limited to IDL data types less than or equal to 63000 bytes or the maximum transmission unit (MTU) of the underlying transport, whichever is smaller.

Also note that Connext Micro does not query the MTU size from the registered transport plugins. If an IDL data-type exceeds the MTU size, the data will be silently discarded.

Connext Micro does not track the maximum receive unit (MRU) of other nodes in the system. Therefore, Connext Micro relies on consistent configuration accross all the nodes in the system in order to successfully send and receive data. For example, if a Connext Micro node has a MRU of 8000 bytes and another Connext Micro node sends 9000 bytes (with a sufficiently large MTU), the data will be sent, but not received.