ZeroDDS rc.3: The complete OMG ecosystem in production-grade Rust #7
Closed
SandraK82
announced in
Announcements
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
If you work with DDS in robotics, automotive, or industrial real-time, you know the friction: a C++ toolchain zoo, per-seat license fees, and stacks that are hard to audit or fork. We asked what a DDS
looks like that's built in Rust from the ground up: memory-safe, a single Cargo workspace, Apache-2.0, no vendor lock-in.
That's ZeroDDS. Today 1.0.0-rc.3 is out, and I'll deliberately also write about what it isn't.
Native RTPS 2.5 wire, interop-verified
ZeroDDS speaks RTPS 2.5 natively, the same OMG-standard protocol as Cyclone DDS, RTI Connext, Fast DDS, and OpenDDS. We don't assert interoperability, we verify it: live against all four stacks (the
OMG Shapes Demo as the reference scenario) and byte-exact against recorded XCDR2 fixtures in CI. 100+ crates, more than 11,000 tests across the workspace.
Breadth, not just DCPS
Beyond DDS-DCPS 1.4 we've implemented XTypes 1.3, DDS-Security 1.2, DDS-RPC, DDS-XML, and DDS-XRCE, plus bridges to MQTT, AMQP, CoAP, gRPC, WebSocket, and ROS 2, and seven language bindings: C, C++,
C#, Java, Python, TypeScript, and Rust. Every spec claim is backed by a section-by-section audit ledger (the public spec-coverage matrix), and every performance number is reproducible with the public
benchmark harness via
cargo bench, full HdrHistogram output.ROS 2: we didn't guess where it hurts, we catalogued it
Before we put "ROS 2 support" on a slide, we collected 349 real-world ROS↔DDS pain reports from the community (discovery storms, silent QoS mismatches, WiFi, large data, scaling, config hell) and
engineered specifically against them:
rmw_cyclonedds)and built a diagnostic CLI:
zerodds-ros2-shim doctorflags the most common WiFi misconfig (multicast-free with no unicast peers) as a hard error, discovery-independent.participants=0. Fix: an initial-announcement burst (10×200 ms untilmatched), proven on a real WiFi rig.
multi_robot()profile: unicast-only discovery, no multicast storm.ros2 topic info -vwith real GUID to node resolution (new in rc.3).Out of the box via
rmw_zerodds, rclpy and rclcpp.And if your stack isn't DDS at all: ZeroDDS is also a complete CORBA 3.3 ORB
Sounds like two worlds, but it's one codebase: the same Rust implementation speaks GIOP/IIOP alongside RTPS. For anyone with a CORBA estate in finance, telco, or defense whose ORB vendor is dying, this
is the real lever. Not a theoretical migration plan, but a drop-in test: throw your legacy system at ZeroDDS without rewriting a line.
Complete means complete: GIOP 1.0 to 1.2, POA, CSIv2/GSSUP security, valuetypes (including chunked wire with nested children), AMI/AMH (async client and server), Bidirectional GIOP, Portable
Interceptors, Interface Repository, RT-CORBA, plus the Object Transaction Service (two-phase commit) and CosTrading.
And it's cross-ORB wire-validated against real foreign ORBs: valuetypes byte-exact against JacORB 3.9 (bidirectional), GSSUP and OTS wire byte-exact against JacORB, the Bidirectional service context
against omniORB. It goes down to a live handshake where JacORB calls back into a ZeroDDS callback over the same connection, and a JacORB OTS
Current.begin()propagates its transaction context to aZeroDDS server.
New in rc.3
shm_open/mmapon Linux and macOS) now runs on Windows too viaCreateFileMapping, with correct owner-create race serializationvia
LockFileEx. Tested on a real Windows runner, not just "it compiles."ros2 topic info -vresolves endpoint GUIDs to node names.What's next, heading toward rc.4
A toolbox that becomes an operator story. The pieces already ship:
idlc,dds-lint, amonitorwith Prometheus and OTLP, deterministic record-and-replay (.zddsrec), wire inspection (spy,snitch,pcap), a conformance harness, a chaos injector, and a routing service. rc.4's job is to turn that pile into a mapped, task-oriented toolbox: a "which tool for which job" matrix,tool-to-subsystem cross-linking, and real recipes instead of flag references. The capability is there; the operability story is what we're finishing.
ROS 2 across distros, gated in CI. The
rmw_zeroddssurface is code-complete (pub/sub, services, wait-sets, loaning, REP-2009, nothing leftUNSUPPORTED). rc.4 adds a continuous liveros2smokeas a green CI gate across Humble, Iron, and Jazzy, so multi-distro interop is verified on every commit, not by hand.
Embedded, on the horizon. Honest about its stage: a
no_stdsafe subset (foundation, CDR, the XRCE client) already builds for Cortex-M (thumbv7em-none-eabihf) on every commit, and DDS-XRCE 1.0,the OMG's micro-DDS for constrained devices, ships today with client and agent. The direction is a fuller DCPS micro-edition so the same Rust types and wire run from a workstation down to an MCU. It's
a direction, not a dated milestone, and we'll say so until it's real.
And honestly, what it isn't
It's a release candidate, not 20 years production-hardened. On performance, across real workloads we're on par with the established stacks: not uniformly ahead, and the RT-tuned commercial pro
configurations are a different league we don't claim to beat. An OMG Vendor-ID has been filed but not yet assigned. We are not safety-certified (ISO 26262, IEC 62304, DO-178C).
If you're evaluating DDS in Rust, need multi-vendor interop, have to migrate a dying CORBA landscape, or just want an auditable, license-free stack: try rc.3 and tell us where it breaks.
Get started
cargo add zerodds-dcpszerodds-idlcRMW_IMPLEMENTATION=rmw_zerodds_cppLinks: https://zerodds.de · https://github.com/zero-objects/zero-dds
All reactions