# Eclipse Cyclone DDS: a C implementation of the OMG data-centric middleware

> The C core of the Cyclone DDS project, a performant implementation of the OMG DDS 1.4 specification with zero-configuration discovery, QoS policies, the XTypes structural type system and DDS Security, and the tier-1 middleware for ROS 2. The gaps are documented rather than hidden, including caveats around XTypes and partial profile coverage.

**eclipse-cyclonedds/cyclonedds** — Eclipse Cyclone DDS project

- Repository: https://github.com/eclipse-cyclonedds/cyclonedds
- Website: https://projects.eclipse.org/projects/iot.cyclonedds
- Stars: 1,362 · Forks: 491
- Language: C
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/eclipse-cyclonedds-cyclonedds

## What DDS is, and why a shared data space instead of a broker

Eclipse Cyclone DDS is a very performant and robust open-source implementation of the OMG DDS specification. The README makes a larger claim about what that means.

DDS is used in a wide variety of systems, including air-traffic control, jet engine testing, railway control, medical systems, naval command-and-control and smart greenhouses. It is well-established in aerospace and defence but no longer limited to that.

The architectural argument is the interesting part. Today DDS is popular in robotics and autonomous vehicles because those domains depend on high-throughput, low-latency control systems without introducing a single point of failure by having a message broker in the middle. DDS is by far the most used and the default middleware choice in ROS 2, and it is used to transfer commands, sensor data and even video and point clouds between components.

The deeper framing is a shared data space, described as an old idea and really just a distributed database. The README says most shared data space designs have failed miserably in real-time control systems because they provided strong consistency guarantees and sacrificed too much performance and flexibility. The eventually consistent shared data space of DDS has instead helped build systems needing dependability, maintainability, extensibility and upgradeability.

The claim at the end is that this is why DDS was invented, and publish-subscribe messaging was simply an implementation technique.

## The type system is what makes DDS different from a message bus

The OMG DDS specifications cover everything needed to build systems on publish-subscribe messaging, but the README puts the weight on the type system rather than on the messaging.

They define a structural type system that allows automatic endianness conversion and type checking between readers and writers, and that type system also supports type evolution. On top of that sit the interoperable networking protocol and the standard C++ API, which is what makes it easy to build systems that integrate multiple DDS implementations. Zero-configuration discovery is included in the standard and supported by all implementations.

So a DDS reader and writer do not merely exchange bytes. They agree on a type, and a mismatch is a type error rather than a deserialisation accident. That is the difference between DDS and a broker with opaque payloads, and it is why the specification has separate documents for each piece.

The specifications Cyclone covers, with references to the individual OMG documents, are DCPS as the base specification, DDS Security for authentication, access control and encryption, the DDS C++ API, DDS XTypes for the structural type system, and DDSI-RTPS as the interoperable network protocol.

The README is careful about the edges. Within DCPS, coverage includes the Minimum, Ownership and, partially, the Content profiles. XTypes comes with caveats, and the repository points at `docs/dev/xtypes_relnotes.md` for them. DCPS also brings zero configuration discovery, though the README qualifies that with the condition that it works if multicast works.

Cyclone aims at full coverage of the specifications and, the README says, already covers most of it.

## Defining types in Python without writing IDL

Types are usually defined in IDL and preprocessed with the IDL compiler included in Cyclone, but the Python binding, in a sibling repository, allows you to define data types on the fly. The README's example makes the point with a comment: C and C++ require using IDL, Python does not.

The imports are ordinary:

```python
from dataclasses import dataclass
from cyclonedds.domain import DomainParticipant
from cyclonedds.core import Qos, Policy
from cyclonedds.pub import DataWriter
from cyclonedds.sub import DataReader
from cyclonedds.topic import Topic
from cyclonedds.idl import IdlStruct
from cyclonedds.idl.annotations import key
from time import sleep
import numpy as np
```

And the type itself is a dataclass with a key annotation:

```python
@dataclass
class Chatter(IdlStruct, typename="Chatter"):
    name: str
    key("name")
    message: str
    count: int
```

The rest of the example wires up a participant, a topic with a reliability policy, a writer and a reader, and then loops writing samples and taking them back. The QoS is set on the topic with `Qos(Policy.Reliability.Reliable(0))`, and the `key` annotation marks which field identifies the instance, which is the DDS concept of a key that identifies an instance within the topic.

The loop uses `sleep(rng.exponential())`, with numpy's random generator, so the writes are randomly spaced rather than periodic. That is a small detail that matters when you are measuring a data fabric under realistic load rather than in a tight loop.

## Where the C core ends and the bindings begin

This repository provides the core of Cyclone DDS including its C API. The OMG C++ implementation and the Python language bindings are in sibling repositories, `eclipse-cyclonedds/cyclonedds-cxx` and `eclipse-cyclonedds/cyclonedds-python`.

That split matters for anyone planning an adoption. If your application is in C, this repository is the whole thing. If you write C++, you are depending on a separate repository with its own release cadence, and the same goes for the Python binding. The interoperability promise of DDS is what makes that split survivable in practice, since a C++ application and a Python application can still talk over the wire, but the release schedules are not synchronised.

The language bindings are therefore not a detail of this repository, which explains why the Python example above lives in the README as an illustration of the model rather than as a component you build here.

The build itself is CMake. The top level holds `CMakeLists.txt`, a `CMakeCPack.cmake` for packaging, a `PackageConfig.cmake.in` and a `PkgConfig.pc.in` for the two integration mechanisms, and a `cmake/` directory of modules. There is a `colcon.pkg` file, so the project can be built as part of a ROS 2 colcon workspace, and a `package.xml` alongside it for the ROS packaging format.

The `ports/` directory holds the platform ports, `compat/` holds compatibility shims, and `fuzz/` is a presence worth noting for a C networking library. Continuous integration runs on Azure Pipelines through `azure-pipelines.yml` and the `.azure/` directory, and there is a codecov configuration, a Coverity badge in the README header, and a `.pre-commit-config.yaml` for local checks.

## The examples directory maps onto the questions you will ask

The `examples/` directory is organised by the question each example answers, which makes it the fastest way to understand the feature surface.

There is `helloworld/`, which is the minimal publisher and subscriber. There is `roundtrip/`, for a publish-subscribe round trip. `listtopics/` is about discovery, letting you see what topics exist on the network. `dynsub/` and `dyntype/` cover dynamic subscription and dynamic type features. `perfscript/` is about scripted performance measurement, and `throughput/` is the throughput measurement example.

The presence of `dyntype/` and `dynsub/` is a good signal about the project's direction, since dynamic types are where XTypes implementations differ most between vendors, and an example that exercises them is a way of finding out whether the implementation handles your case.

The `fuzz/` directory at the repository root is a separate and more serious matter. A C library that parses network input is exactly the kind of target that benefits from fuzzing, and having a fuzzing setup in the tree says the project takes input parsing seriously. The `docs/` directory, `CHANGELOG.rst` in reStructuredText, `ROADMAP.md`, `SECURITY.md`, `CONTRIBUTING.md` and `CYCLONEDDS_QUALITY_DECLARATION.md` complete the picture of a project with a formal governance and documentation practice.

The quality declaration file is the one to read first. It is the artifact where a project states which parts of a standard it supports, and for a specification-driven middleware that replaces a lot of trial and error.

## Licence, versioning and the status of the project

The README header carries two licence badges, EPL 2.0 and EDL 1.0, and the GitHub metadata records the licence as a custom one that cannot be classified, with a pointer to the `LICENSE` file. The `NOTICE.md` file sits at the root alongside it. A dual EPL and EDL arrangement is the standard Eclipse pattern, offering a copyleft option and an alternative permissive-style option, and the `LICENSE` file is where you check which applies to your distribution.

The version scheme changed recently, and the release list shows it. The recent releases are 11.0.1 from 2026-03-20, 11.0.0 from 2026-02-19, and then 0.10.5 from 2024-05-17. So the project jumped from a 0.x line to an 11.x line, which is a major versioning change that will affect how you pin and how you read the changelog.

The release names are also unusual, being rendered as phrases in the release list, but that is packaging metadata rather than something that affects the code.

The repository is not archived and the last push was on 2026-10-13, so work is landing on the default branch, master. The build badge points at Azure Pipelines with a coverage badge, and the network stack section of the README claims the stack has been around for over a decade in one form or another and has proven itself in many systems, including large, high-availability ones and systems where interoperability with other implementations was needed.

The Cyclone project is an Eclipse IoT project, developed completely in the open, with a growing list of adopters.

## Where Cyclone DDS is the wrong choice

The clearest wrong case is a workload that wants a broker. DDS is a peer-to-peer data fabric, and a participant is a full participant in the network with its own discovery traffic, its own history cache and its own quality-of-service configuration. A system that wants one administrative endpoint, one place to see all subscriptions, and topic-level retention policies is describing a broker, and DDS will not give you that without building it yourself.

The second wrong case is a team that needs the complete OMG specification set. The README says Cyclone aims at full coverage and covers most of it, and then lists what that means in practice: the Content profile is only partially covered, and XTypes comes with caveats documented in `docs/dev/xtypes_relnotes.md`. If your interoperability requirement is written as a conformance claim to a particular profile, you have to check the coverage against the claim rather than against the ambition.

The third is a dependency on multicast. Zero-configuration discovery depends on multicast working, and the README says so as a condition. A network with multicast filtered or unavailable needs a discovery server or a configured unicast peer list, and the README here does not document that path, so it is worth checking the documentation for your network shape.

The fourth is a project that wants a single repository. As noted, the C++ and Python bindings live elsewhere, so a Python team is taking a dependency on a different repository with its own release schedule, and the interoperability between the two is a promise rather than a build artefact.

What Cyclone offers in exchange is a high-performance peer-to-peer middleware in C with a decade of production history, and tier-1 status as ROS 2 middleware.

## Conclusion

Cyclone DDS suits a systems team building a peer-to-peer data fabric where a central broker is unacceptable, and who want the OMG specifications implemented in C with the C++ and Python bindings available in sibling repositories. It does not suit a team that needs a message broker with topic-level durability, a single administrative endpoint, or a subscription model other than a shared data space. Before adopting it, read `CYCLONEDDS_QUALITY_DECLARATION.md` and `ROADMAP.md` to see which specification profiles are actually covered, check the XTypes caveats in `docs/dev/xtypes_relnotes.md` if your type system depends on optional XTypes features, and confirm your platform is in the `ports/` directory before assuming the build is portable.

## FAQ

### What is Cyclone DDS and which specification does it implement?

Eclipse Cyclone DDS is a C implementation of the OMG DDS specification, described as very performant and robust. It covers the DCPS base specification, DDS Security, the DDS C++ API, DDS XTypes and the DDSI-RTPS interoperable network protocol, with partial coverage of the Content profile.

### Do I need to write IDL to use Cyclone DDS?

For C and C++ you do, since types are usually defined in IDL and preprocessed with the IDL compiler included in Cyclone. The Python binding in a sibling repository lets you define types on the fly as dataclasses with key annotations.

### Is Cyclone DDS the default middleware for ROS 2?

The README states that DDS is by far the most used and the default middleware choice in ROS 2, and that Cyclone DDS is a tier-1 middleware for it. It is used to transfer commands, sensor data, video and point clouds between components.

### Where are the C++ and Python bindings for Cyclone DDS?

They are in sibling repositories, `eclipse-cyclonedds/cyclonedds-cxx` and `eclipse-cyclonedds/cyclonedds-python`. This repository provides the core of Cyclone DDS including its C API.

### Does Cyclone DDS need a message broker?

No. The README explains that DDS is used in robotics and autonomous vehicles because those domains need high-throughput, low-latency control systems without introducing a single point of failure by having a message broker in the middle.

## Sources

- [eclipse-cyclonedds/cyclonedds on GitHub](https://github.com/eclipse-cyclonedds/cyclonedds)
- [Issues](https://github.com/eclipse-cyclonedds/cyclonedds/issues)
- [Project website](https://projects.eclipse.org/projects/iot.cyclonedds)
- [README](https://github.com/eclipse-cyclonedds/cyclonedds/blob/master/README.md)
- [Releases](https://github.com/eclipse-cyclonedds/cyclonedds/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eclipse-cyclonedds-cyclonedds