A messaging protocol for the cloud based on DDS concepts.
The Data Distribution Service for Real-Time Systems (DDS) is an Object Management Group (OMG) machine to machine middleware standard that aims to enable scalable, real-time, dependable, high performance and interoperable data exchanges between publishers and subscribers. DDS is designed to address the needs of applications like financial trading, air traffic control, smart grid management, and other big data applications. The standard is used in applications such as smartphone operating systems, transportation systems and vehicles, software defined radio, and by healthcare providers. DDS plays a large role in the Internet of Things.
More information on DDS can be found here:
It is crucial to understand the concepts behind DDS to use full power of CloudDDS, however, basics should be quite straightforward to grasp.
This project is going to include a number of examples presenting more complex use cases.
How does it work?
The main DDS concepts are:
- data readers
- data writers
DDS also offers MultiTopics and ContentFilteredTopics. All these concepts will be available in the first release of CloudDDS.
Concept - subject to change
In CloudDDS channels are represented by ports. Each
data reader opens a UDP server on a port assigned to a channel. Channel information is distributed across the overlay to every
data reader and
Redis is used a cache for the data storage layer on both the
Topics consist of topic name and topic type. Here we have a slight deviation from DDS, CloudDDS uses MessagePack for data compression for wire transport. Supported data types:
All these types map directly to MessagePack types.
MultiTopics and ContentFilteredTopics
In addition to standard Topics, there are also constructs in place for MultiTopics and ContentFilteredTopics.
A MultiTopic is a logical grouping of several Topics. It allows an application to select fields from multiple types and recombine them into a new type (something like an
SQL SELECTstatement). As a large application evolves, MultiTopics can be a powerful tool: the data types used within a subsystem may change, but the contents of those new types can be recombined to look like the old types, preserving the interface between subsystems.
A ContentFilteredTopic allows you to declare a filter expression by which only individual data samples of the specified Topic would be received and presented to the application. In our simple example, this would allow some subscribers to only receive and process data when a temperature exceeded a specific limit.
Quality of Service
All DDS QoS parameters should be supported:
- Destination Order
- Entity Factory
- Group Data
- Latency Budget
- Ownership Strength
- Reader Data Lifecycle
- Resource Limits
- Time-Based Filter
- Topic Data
- Transport Priority
- User Data
- Writer Data Lifecycle
Author: Rad Gruchalski (firstname.lastname@example.org)
This work will be available under Apache License, Version 2.0.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.