Retina
The same DDS model, designed for Rust
Retina is the Rust implementation of the Tinverse DDS design. Its typed API covers participants, topics, writers, readers, discovery, reliable delivery, fragmentation, shared memory, and durable history.
Retina runs as standalone DDS middleware; ROS is not required. Rust ownership ties loans, retained samples, sockets, and service tasks to clear lifetimes, making shutdown and failure behavior easier to follow.
What works today
- A typed publish/subscribe API with DDS type support derived from Rust types.
- SPDP and SEDP discovery with reliable RTPS delivery and repair.
- Implicit shared memory for same-host peers and UDP for remote peers.
- Bounded reader and writer histories, late-reader replay, and persistence.
- Linux and Windows builds with machine-readable benchmark evidence.
- Security policy and cryptographic building blocks shared with Tin DDS.
Why Rust?
Loans have owners
A shared-memory loan cannot be used after it is released. The compiler checks that lifetime instead of leaving it to convention.
Services have lifetimes
Discovery and repair tasks belong to an owning runtime object with cancellation and join paths. They are not detached background work.
Bounds are part of the API
Histories and protocol state have configured limits. Full storage produces an explicit error instead of an unexpected allocation spike.
Transport
One Rust API for shared memory and the network
Retina uses shared memory for same-host peers and UDP for remote peers. Applications keep the same typed writer and reader API while transport selection remains automatic.
C++ and Rust
Two implementations, one behavior contract
Tin DDS and Retina share requirement IDs and wire examples for discovery, reliability, history, security, and teleoperation. A C++ controller and a Rust service can agree on the wire while each uses the ownership style natural to its language.
Security
A clear line between components and completion
Retina validates certificates, signed governance, handshake transcripts, key agreement, and protected-message primitives. Runtime handshake and permissions wiring remain in progress; cryptographic code alone is not presented as a complete secured DDS domain.
Performance
Measured through the real product path
The public benchmark uses persistent publisher and subscriber processes, full discovery and reliability, delivery counters, and the same 64-byte workload contract used for the comparison cohort.
No ROS required to build or run it
Retina builds and runs as standalone DDS middleware. Optional integrations stay outside the measured data path so their cost remains visible.
Open the DDS benchmark suite →Contact engineering@tinverse.com.