Sidebar
This is an old revision of the document!
Table of Contents
OMG: DDS Interoperability Wire Protocol (DDSI-RTPS)
return to the DDS Family of Standards
| Title | DDS Interoperability Wire Protocol |
| Acronym | DDSI-RTPS |
| Version | 2.3 |
| OMG Document Number | formal/19-04-03 |
| Release Date | May 2019 |
| About Specification | https://www.omg.org/spec/DDSI-RTPS/ |
| Document | https://www.omg.org/spec/DDSI-RTPS/2.3/PDF |
- Note: The following is an excerpt from the actual document. It is provided here as a convenience and is not authoritative. Refer to the original document as the authoritative reference.
Overview
- This specification defines an interoperability wire protocol for data_distribution_service_dds. Its purpose and scope is to ensure that applications based on different vendors’ implementations of DDS can interoperate.
Introduction
The recently-adopted Data-Distribution Service specification defines an Application Level Interface and behavior of a data_distribution_service_dds that supports dcps inreal-time systems. The DDS specification used a model_driven_architecture approach to precisely describe the data_centric communications model specifically:•how the application models the data it wishes to send and receive,
- how the application interacts with the DCPS middleware and specifies the data it wishes to send and receive as well as the Quality of Service (QoS) requirements,
- how data is sent and received (relative to the QoS requirements),
- how the applications access the data,and
- the kinds of feedback the application gets from the state of the middleware.
The DDS specification also includes a platform specific mapping to idl and therefore an application using DDS is able to switch among DDS implementations with only a re-compile. DDS therefore addresses ‘application portability.’
The DDS specification does not address the protocol used by the implementation to exchange messages over transports such as TCP/UDP/IP, so different implementations of DDS will not interoperate with each other unless vendor-specific “bridges”are provided.The situation is therefore similar to that of other messaging API standards such as JMS.
With the increasing adoption of DDS in large distributed systems, it is desirable to define a standard “wire protocol” that allows DDS implementations from multiple vendors to interoperate. The desired “DDS wire protocol” should be capable of taking advantage of the QoS settings configurable by DDS to optimize its use of the underlying transport capabilities. In particular, the desired wire protocol must be capable of exploiting the multicast, best-effort, and connectionless nature of many of the DDS QoS settings
Source: DDSI-RTPS v2.2
