Data Distribution Service (DDS) in a Nutshell

Let’s talk about DDS — and no, we’re not talking about a dental degree here. We’re diving into the Data Distribution Service, the middleware messaging system that quietly powers a lot of the high-stakes tech you never hear about in the news.

If you’re building military systems, autonomous vehicles, aerospace comms, or any real-time distributed system where latency isn’t just a number but a matter of life and death — then DDS might already be your best friend (or soon will be).

🧠 What the Heck Is DDS?

DDS stands for Data Distribution Service for Real-Time Systems. It’s an OMG (Object Management Group) standard for real-time publish/subscribe communication.

Think of it like a data delivery ninja:
📦 Data gets published
🎯 Subscribers get it instantly
⚡ No polling, no REST APIs, no middlemen

It’s peer-to-peer, decentralized, and built to be ultra-fast and ultra-reliable.

🚀 Key Features That Make DDS Shine

🔄 Publish/Subscribe Model

Publishers write data to a topic.
Subscribers get updates only if they care about that topic.

No hand-holding or coordination between sender and receiver needed. It’s data-centric, not message-centric — this means you’re publishing state, not just sending messages.

⏱️ Real-Time Communication

DDS is optimized for hard and soft real-time systems. You can define Quality of Service (QoS) policies like:

• Deadline (e.g. data every 10 ms)
• Latency budget
• Reliability (best-effort or guaranteed delivery)
• Lifespan (data expiration)
• Ownership (who controls a data topic)

These QoS settings allow fine-tuned performance, reliability, and determinism that’s impossible with general-purpose messaging systems like MQTT or Kafka.

🧱 Decentralized Architecture

No central broker. No single point of failure. DDS participants discover each other dynamically via discovery protocols.

This makes it robust and scalable — perfect for environments where connections come and go, like:

• UAV swarms
• Shipboard systems
• Mobile sensor networks

🔐 Built-in Security

DDS Security is an OMG standard extension that adds:

• Authentication
• Authorization
• Encryption
• Access control
• Logging

Because, you know, “combat drone sends telemetry to wrong subscriber” isn’t exactly ideal.

🛠️ Common DDS Implementations

There are multiple vendors, open-source and commercial, that provide DDS implementations:

🛰️ DDS in the Wild: Where It’s Used

DDS isn’t a household name — but it runs behind the scenes in systems where failure isn’t an option:

• DoD weapon systems (e.g., Aegis Combat System, missile defense)
• Avionics and flight control systems
• Medical devices
• Autonomous vehicles (e.g., with ROS 2 using Fast DDS)
• Spacecraft telemetry
• Industrial control and SCADA systems

Basically, if your software can blow up, crash, or save lives, DDS might be your middleware.

🧪 How DDS Works — In Simple Terms

Let’s walk through a scenario.

🎓 Say Hello to Topics

Imagine a topic called TargetLocation.

• A radar system publishes updates to TargetLocation.
• A missile guidance system subscribes to TargetLocation.

DDS automatically:

• Finds the publisher and subscriber
• Matches QoS settings
• Starts the data flow
• Delivers updates as fast as the wire will allow

No explicit connection, no central registry, no polling.

⚙️ The DDS Stack

The DDS architecture is layered like an onion (but less likely to make you cry):

1. DCPS (Data-Centric Publish-Subscribe): The core API.
2. DDS RTPS (Real-Time Publish-Subscribe protocol): Wire protocol for interop.
3. DDS Security: Optional, layered on top.

It’s all about modularity and portability — and yes, you can use it across languages like C++, C, Java, Python, and even Rust (with some community help).

🧩 DDS vs. Other Messaging Systems

💡 When Should You Use DDS?

DDS is great for:

• Real-time control systems
• Safety-critical systems
• Systems requiring fine-grained QoS
• Distributed systems without a broker

DDS might be overkill for:

• Simple IoT telemetry (use MQTT)
• Log aggregation (use Kafka)
• Internal RPC calls (use gRPC)

But if reliability, latency, and scalability are non-negotiable, DDS is hard to beat.

🧰 Getting Started with DDS

You can dive in with open-source:

• eProsima Fast DDS
• OpenDDS

Or try commercial offerings with great tooling:

• RTI Connext DDS
• ADLINK OpenSplice

Pro tip: DDS is super configurable, so expect to spend time tweaking QoS, topics, and discovery parameters. But once it’s tuned — it flies.

Getting Started with DDS: Code Samples and Concepts

🧰 Tools You’ll Need

We’ll use eProsima Fast DDS for these examples because:

• It’s open source
• Well-documented
• Actively maintained
• Used in ROS 2 and other modern systems

🛠️ Install Fast DDS (Ubuntu example)

1
2

sudo apt update
sudo apt install fastdds fastdds-tools

Or build from source if you like pain:
👉 Fast DDS GitHub

🧪 Basic Concepts in Code

DDS applications usually involve the following steps:

1. Create a DomainParticipant
2. Define a Topic with a data type
3. Create a Publisher or Subscriber
4. Use DataWriter (to publish) or DataReader (to subscribe)
5. Configure QoS as needed

🐣 Step 1: Define Your Data Type

DDS uses IDL (Interface Definition Language) to define data types.

Create a file called HelloWorld.idl:

1
2
3
4
5
6

module HelloWorldModule {
  struct HelloWorld {
    string message;
    long index;
  };
};

Then generate C++ code using Fast DDS tools:

1

fastrtpsgen -example x64Linux2.6gcc HelloWorld.idl

This gives you:

• Type support classes
• Example publisher/subscriber stubs

📤 Step 2: Create a Publisher

Here’s a minimal publisher using Fast DDS:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

#include "HelloWorldPubSubTypes.h"
#include "HelloWorld.h"
#include <fastdds/dds/domain/DomainParticipantFactory.hpp>
#include <fastdds/dds/publisher/DataWriter.hpp>
#include <fastdds/dds/topic/Topic.hpp>
#include <fastdds/dds/publisher/Publisher.hpp>
#include <iostream>

using namespace eprosima::fastdds::dds;

int main()
{
    DomainParticipantQos participant_qos;
    DomainParticipant* participant =
        DomainParticipantFactory::get_instance()->create_participant(0, participant_qos);

    TypeSupport type(new HelloWorldModule::HelloWorldPubSubType());
    type.register_type(participant);

    Topic* topic = participant->create_topic("HelloTopic", type.get_type_name(), TOPIC_QOS_DEFAULT);

    Publisher* publisher = participant->create_publisher(PUBLISHER_QOS_DEFAULT, nullptr);
    DataWriter* writer = publisher->create_datawriter(topic, DATAWRITER_QOS_DEFAULT, nullptr);

    HelloWorldModule::HelloWorld data;
    data.message("Hello DDS!");
    data.index = 1;

    std::cout << "Publishing: " << data.message() << std::endl;
    writer->write(&data);

    std::this_thread::sleep_for(std::chrono::seconds(1));
    DomainParticipantFactory::get_instance()->delete_participant(participant);
    return 0;
}

Compile and run, and voilà — you’ve got yourself a DDS publisher.

📥 Step 3: Create a Subscriber

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

#include "HelloWorldPubSubTypes.h"
#include "HelloWorld.h"
#include <fastdds/dds/subscriber/DataReaderListener.hpp>
#include <fastdds/dds/subscriber/SampleInfo.hpp>
#include <iostream>

using namespace eprosima::fastdds::dds;

class HelloListener : public DataReaderListener
{
public:
    void on_data_available(DataReader* reader) override {
        HelloWorldModule::HelloWorld data;
        SampleInfo info;
        if (reader->take_next_sample(&data, &info) == ReturnCode_t::RETCODE_OK && info.valid_data) {
            std::cout << "Received: " << data.message() << " [" << data.index << "]" << std::endl;
        }
    }
};

int main()
{
    DomainParticipant* participant =
        DomainParticipantFactory::get_instance()->create_participant(0, PARTICIPANT_QOS_DEFAULT);

    TypeSupport type(new HelloWorldModule::HelloWorldPubSubType());
    type.register_type(participant);

    Topic* topic = participant->create_topic("HelloTopic", type.get_type_name(), TOPIC_QOS_DEFAULT);
    Subscriber* subscriber = participant->create_subscriber(SUBSCRIBER_QOS_DEFAULT, nullptr);

    HelloListener* listener = new HelloListener();
    DataReader* reader = subscriber->create_datareader(topic, DATAREADER_QOS_DEFAULT, listener);

    std::cout << "Waiting for data..." << std::endl;
    std::this_thread::sleep_for(std::chrono::seconds(10));

    DomainParticipantFactory::get_instance()->delete_participant(participant);
    delete listener;
    return 0;
}

Run the subscriber first, then the publisher. Boom 💥 — you just made a distributed, real-time messaging system. No server, no broker, no tears.

🔧 Tweaking QoS

Want reliability? Add this to the QoS config:

1
2
3
4

DataWriterQos writer_qos = DATAWRITER_QOS_DEFAULT;
writer_qos.reliability().kind = RELIABLE_RELIABILITY_QOS;

DataWriter* writer = publisher->create_datawriter(topic, writer_qos, nullptr);

Want data to expire after 5 seconds?

1

writer_qos.lifespan().duration = eprosima::fastrtps::c_TimeInfinite;

You can tweak deadline, durability, history, liveliness, etc. DDS is basically QoS heaven.

🚁 Real Use Cases Revisited

These small examples can scale to control:

• Swarms of autonomous drones
• Real-time shipboard sensors
• Distributed radar systems
• Tactical data links

All using the same basic DDS pattern.

🔑 Key Ideas