What is RTPS?
RTPS (Real Time Publish Subscribe Protocol) is a protocol for best effort and reliable pub-sub communications over unreliable transports such as UDP in both unicast and multicast.
RTPS has been standardized by the OMG (Object Management Group) as the interoperability protocol for Data Distribution Service (DDS) implementations, an standard widely used in the aerospace and defense sectors for real-time applications.
Besides the RTPS implementations embedded in the different DDS implementations, there are standalone lightweight RTPS implementations, being eProsima Fast DDS the leading one in terms of performance, features and adherence to the latest release of the RTPS standard (RTPS 2.2).
RTPS advantages:
The main features of the RTPS protocol are:
- Performance and Quality-of-Service (QoS) properties enabling best-effort and reliable publish-subscribe communications for real-time applications using standard IP networks.
- Fault tolerance allowing the creation of networks without single points of failure.
- Extensibility allowing backward compatibility and interoperability through extensions of the protocol and enhancement with new services.
- Plug-and-play connectivity for new applications and services allowing automatic, configuration-less discovery by applications joining and leaving the network at any time.
- Configurability allowing balancing the requirements of reliability and timeliness for each data delivery transaction.
- Modularity allowing simple devices to implement a subset of the protocol and still participate in the publish-subscribe network.
- Scalability enabling systems to scale to very large publish-subscribe networks.
- Type-safety preventing application programming errors compromising the operation of remote nodes in the publish-subscribe network.
RTPS architecture:
The RTPS wire protocol is based on four different modules that control the exchange of information between the different DDS applications.
- The Structure module defines the communication endpoints and maps them to their DDS counterparts.
- The Message module defines which messages can these endpoints exchange and how they are built.
- The Behavior module defines a set of legal interactions and how they affect each of the endpoints.
- The Discovery module defines a set of built-in endpoints that allow the automatic discovery.
A brief explanation of each of the modules and their parts is included below:
Structure module:
Since RTPS is the wire protocol designed to implement DDS applications, each DDS concept or entity naturally maps to an RTPS entity. All RTPS entities are associated with an RTPS domain, which represents a separate communication plane that contains a set of Participants. Each RTPS Participant can contain multiple local Endpoints of two different kinds: Writers and Readers. These two endpoints exchange information in the RTPS network by sending RTPS messages. The Writers send the locally available information to the Readers, which, in turn can request or acknowledge the data.
The interface between the RTPS endpoints (Writer and Readers) and its corresponding DDS entities is the HistoryCache. The information exchanged between the endpoints its usually stored in a CacheChange. For example, each write operation introduces a CacheChange in the Writer History. The RTPS Writer then sends an RTPS message to all matching Readers. Upon receipt, the RTPS Reader adds the CacheChange to its corresponding HistoryCache and notifies the DDS entity that a new data is available.
Message module:
The messages module defines the content of the atomic information exchanges between RTPS Writers and Readers. RTPS Messages are composed of a header followed by a number of Submessages. The Header identifies the message as part of the RTPS protocol, as well as the version of the protocol being used and the vendor that sent the message. It also identifies the Participant that is sending the message.
Each Submessage is composed of a Submessage Header and a series of Submessage elements. This structure is chosen to allow the vocabulary of Submessages and the composition of each Submessage to be extended while maintaining backward compatibility. The Submessage Header contains the submessage Id that identifies the type of submessage, the submessage length in bytes and the submessage flags. There are twelve different kind of submessages. For a complete description of all messages, its composition and interpretation please consult the OMG RTPS specification document. The three most important messages are:
- DATA: This submessage is sent from a Writer to a Reader with information regarding a change to a data-object belonging to a Writer. This change can be in value (new information being added) or in the life-cycle (a previously sent data is no longer valid).
- HEARTBEAT: This submessage is sent from a Writer to a Reader communicating the CacheChanges that the Writer has available at this moment.
- ACKNACK: This submessage is sent from a Reader to a Writer, and allows the Reader to notify the Writer about which changes it has received and which ones are still missing. It can be used to do both positive and negative acknowledgements.
Behavior module:
This module describes the valid messages exchanges that can occur between a Writer and a Reader. It also defines the changes in the state of the Writer and Reader depending on each message. A full set of rules can be found in the OMG RTPS specification document. These rules are set in order to ensure interoperability between different implementations.
Discovery module:
This module describes the protocol that enables Participants to obtain information about the existence and attributes of all the other Participants and Endpoints in the Domain. This information exchange is called metatraffic. Once remote endpoints have been discovered, the local endpoints can be configured accordingly to establish communication. The discovery protocol is divided in two layers: Participant Discovery Protocol (PDP) and Endpoint Discovery Protocol (EDP). The PDP specifies how the Participants discover each other. Upon discovery the Participants exchange information about their endpoints using the EDP. Different vendors may implement multiple discovery protocols, however to ensure interoperability one PDP and one EDP must be implemented by all vendors. These discovery protocols are called "Simple" (Simple PDP and Simple EDP) and are very well suited for most applications.
The complete description of the discovery modules can be found in the specification document. However the most important feature of this discovery mechanism is that it allows simple plug and play connectivity, without the need of any configuration by the user.
Additional Information:
For More information about RTPS:
For more information, please contact
