.. _DDS_WireProtocolQosPolicy: ../../../api_c/html/structDDS__WireProtocolQosPolicy.html
.. _rtps_well_known_ports: ../../../api_c/html/structDDS__WireProtocolQosPolicy.html

Introduction
------------

In |rti_me|, DDS entities exchange information using transports. Transports
exhange data with peer transports, and |me| 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 |me| only supports UDPv4 and a special transport for 
  internal communication within a DDS *DomainParticipant*.

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

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

Note that |me| 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 |me| 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. 

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