-
Notifications
You must be signed in to change notification settings - Fork 194
DDS Overview
Specification committees are managed by the Object Management Group (OMG). Self described as a Data-centric Publish Subscribe (DCPS) system. Also defines a Data Local Reconstruction Layer (DLRL) system, which is used at the application level. The DLRL system provides a plain object interface backed by the publish subscribe system.
This presentation has a good overview/timeline of DDS related specifications' evolution:
http://www.slideshare.net/Angelo.Corsaro/dds-for-jms-programmers
http://en.wikipedia.org/wiki/Data_Distribution_Service
The Data Distribution Service for Real-Time Systems (DDS) is described as a Data-Centric Publish Subscribe (DCPS) system. This specification defines the concepts and behavior of the publish subscribe system as well as the generic API. This includes the core concepts, how discovery works, how the connection process behaves, how the API should look, what Quality of Service features exist, etc...
- 1.2 June 1, 2003
- 1.1 December 4, 2005
- 1.0 January 1, 2007
http://en.wikipedia.org/wiki/RTPS_protocol
The "Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol Specification" (DDSI, DDS-I, or sometimes the RTPS protocol) defines the wire protocol which you must adhere to in order to be DDS interoperability compliant.
DDS shifted to this wire format which was based on the existing Real-time Publish-Subscribe wire protocol already in use by industrial electronics vendors in order to better support their use cases as they were potential new customers. I point that out to say that this wire protocol started as something used in industrial automation and electronics, then was adopted by multiple middleware companies as their common interoperability format, which lends to its credibility as something that works.
RTPS is defined by a set of modules, each with a definition as part of the PIM (Platform Independent Module) and definitions in one or more PSM (Platform Specific Module) definitions. This way the general concepts and constraints can be put into the common PIM, while there also exists a PSM for each potential implementation platform, allowing for flexibility in the implementation. For example, the PIM describes discovery and a corresponding PSM describes how to implement discovery on top of multicast UDP/IP. The four modules which make up RTPS are as follows:
- Discovery
- Behavior
- Structure
- Messages
- 2.1 January, 2009
- 2.0 June, 2007
- 1.2 June, 2006
RTPS allows for many different kinds of underlying transports, but all must implement basic unicast UDP/IP. The RTPS protocol was design to only need at least a connectionless service capable of sending packets best-effort. From the spec:
The general requirements RTPS poses on the underlying transport can be summarized as follows:
- The transport has a generalized notion of a unicast address (shall fit within 16 bytes).
- The transport has a generalized notion of a port (shall fit within 4 bytes), e.g., could be a UDP port, an offset in a shared memory segment, etc.
- The transport can send a datagram (uninterpreted sequence of octets) to a specific address/port. The transport can receive a datagram at a specific address/port.
- The transport will drop messages if incomplete or corrupted during transfer (i.e., RTPS assumes messages are complete and not corrupted).
- The transport provides a means to deduce the size of the received message.
Allows you to build DDS applications using UML (Unified Modeling Language). UML is something else the OMG came up with.
This was created in 2008.
This specification, titled "Extensible and Dynamic Topic Types for DDS", is a specification for defining types which can change over time by extension or mutation. This seems to be a replacement for the OMG's IDL system for defining types.
Two Language bindings are described:
- Plain Language Bindings
- Dynamic Language Bindings
The Plain Language Bindings appear to be just accessors for the data of a predefined message. The Dynamic Language Bindings add the ability to programmatically process or mutate type definitions are runtime.
- 1.0 November, 2012
- OpenDDS
- Custom License (LGPL like?)
- ConnextDDS (RTI)
- Weird open license which requires contact info for anyone you distribute it to, be collected and returned to RTI
- OpenSplice (PrismTech)
- LGPL
- Is the OMG IDL serialization required? Can other serialization libraries be used on top of DDS?
- How is the location value for a participant determined (IP address)?
- Can a subscriber detect/specially handle when it is being "caught" up vs real-time data?
- Why not just use topic namespacing?
- Are "dropped" messages sent over the wire?
- How is this handled in multicast situations, are sub->pub connections for TIME_BASED_FILTER'ed limited to p2p unicast?
- How are the conditions formulated, in the host language (test function), or in some proto-language?
- How is this implemented, just use the HistoryCache and wait for some amount of time before giving up on next seq.?
http://www.slideshare.net/JaimeMartin-eProsima/dds-advanced-tutorial-omg-june-2013-berlin-meeting http://www.slideshare.net/GerardoPardo/introduction-to-omg-dds-1-hour-45-slides