Why I Rewrote DDS From Scratch in Rust

The Problem

DDS (Data Distribution Service) is the backbone of modern robotics and aerospace systems. ROS2 uses it. Military systems use it. Space missions use it. Yet every existing implementation feels like it was designed in a different era.

$ ldd /usr/lib/libfastrtps.so | wc -l
47

$ du -sh /opt/ros/humble/lib/libfastrtps*
12M     /opt/ros/humble/lib/libfastrtps.so.2.6.4

47 shared library dependencies. 12MB just for the RTPS layer. And that's before you add your actual application logic.

The Constraints

I set myself three non-negotiable requirements:

• 1 Zero external dependencies in the core library. Not "minimal" - zero.
• 2 Sub-microsecond latency for intra-process communication. No excuses.
• 3 Actually debuggable. When something goes wrong, I want to understand why.

The Architecture

HDDS is built on a foundation of zero-copy message passing. When you publish a message, it doesn't get copied. When a subscriber reads it, no copy happens there either.

// Loan a sample from the writer's pool
let mut sample = writer.loan_sample()?;

// Write directly into shared memory
sample.position.x = sensor.read_x();
sample.position.y = sensor.read_y();
sample.timestamp = now();

// Publish - no copy, just ownership transfer
writer.publish(sample)?;

The secret is SPSC (Single Producer Single Consumer) lock-free ring buffers. Each writer-reader pair gets its own channel. No locks, no contention, no surprises.

The Results

257 nanoseconds to publish a message. That's about 80 CPU cycles on a modern processor. Compare that to FastDDS's typical 15-50 microseconds.

What's Next

HDDS is now powering real systems - robots, satellites, industrial automation. The codebase is stable, well-tested (909 tests passing), and actively maintained.

If you're building something that needs reliable, fast, debuggable data distribution, give it a try. The source is available, the documentation is comprehensive, and I'm always happy to help.