5.6.1. Introduction

RTI Connext Micro has a pluggable-transports 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.

In Connext 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 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 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.