DDS Interoperability Protocol, v2.2 5
7Overview
7.1 Introduction
The recently-adopted Data-Distribution Service specification defines an Application Level Interface and behavior of a
Data-Distribution Service (DDS) that supports Data-Centric Publish-Subscribe (DCPS) in real-time systems. The DDS
specification used a Model-Driven Architecture (MDA) 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.
7.2 Requirements for a DDS Wire-protocol
In network communications, as in many other fields of engineering, it is a fact that “one size does not fit all.” Engineering
design is about making the right set of trade-offs, and these trade-offs must balance conflicting requirements such as
generality, ease of use, richness of features, performance, memory size and usage, scalability, determinism, and
robustness. These trade-offs must be made in light of the types of information flow (e.g., periodic vs. bursty, state-based
vs. event-based, one-to-many vs. request-reply, best-effort vs. reliable, small data-values vs. large files, etc.), and the
constraints imposed by the application and execution platforms. Consequently, many successful protocols have emerged
such as HTTP, SOAP, FTP, DHCP, DCE, RTP, DCOM, and CORBA. Each of these protocols fills a niche, providing well-
tuned functionality for specific purposes or application domains.
The basic communication model of DDS is one of unidirectional data exchange where the applications that publish data
“push” the relevant data updates to the local caches of co-located subscribers to the data. This information flow is
regulated by QoS contracts implicitly established between the DataWriters and the DataReaders. The DataWriter specifies
its QoS contract at the time it declares its intent to publish data and the DataReader does it at the time it declares its intent
to subscribe to data. The communication patterns typically include many-to-many style configurations. Of primary
我的内容管理
展开
