4.6.1. Introduction

RTI Connext DDS Micro has a pluggable-transports architecture. The core of Connext DDS Micro is transport agnostic—it does not make any assumptions about the actual transports used to send and receive messages. Instead, Connext DDS 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.

In Connext DDS Micro a Network Input/Output (NETIO) interface is a software layer that may send and/or receive data from a higher and/or lower level locally, as well as communicate with a peer. A transport is a NETIO interface that is at the lowest level of the protocol stack. For example, the UDP NETIO interface is a transport.

A transport can send and receive on addresses as defined by the concrete transport. For example, the Connext DDS 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 document describes how the addresses are reserved and how these addresses are used by the DDS layer in Connext DDS Micro.

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

Note that Connext DDS Micro 2 does not support RTPS fragmentation and is limited to data types less than or equal to 63000 bytes.