CloudDDS - cloud communication mechanism based on DDS concepts
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.


A messaging protocol for the cloud based on DDS concepts.

What's DDS

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,[1] transportation systems and vehicles,[2] 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?

CloudDDS is a Ruby project, the core of the messaging platform consists of rgossip and Redis.

The main DDS concepts are:

  • channels
  • topics
  • data readers
  • data writers
  • QoS

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 data writer.

Redis is used a cache for the data storage layer on both the reader and writer.


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:

  • nil
  • int
  • float
  • boolean
  • string
  • binary
  • array
  • map
  • ext

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 SELECT statement). 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:

  • Deadline
  • Destination Order
  • Durability
  • Entity Factory
  • Group Data
  • History
  • Latency Budget
  • Lifespan
  • Liveliness
  • Ownership
  • Ownership Strength
  • Partition
  • Presentation
  • Reader Data Lifecycle
  • Reliability
  • Resource Limits
  • Time-Based Filter
  • Topic Data
  • Transport Priority
  • User Data
  • Writer Data Lifecycle



Author: Rad Gruchalski (

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.