Core OMG-spec layers
Eight OMG specifications, all implemented end-to-end. From DCPS Public API at the top to UDP / TCP / shared-memory transports at the bottom — each layer is its own crate, each crate ships with a spec-coverage report.
Learn — what are the core layers?
DDS is a layered system. At the top sits the DCPS Public API — what a developer's code calls (DomainParticipant, Topic, DataWriter, DataReader). Underneath that is the discovery layer, then the RTPS wire protocol, then the transport (UDP, TCP, or shared memory).
OMG has standardised this stack across eight specifications. DDS 1.4 is the API surface and QoS model. DDSI-RTPS 2.5 is the wire protocol. XTypes 1.3 governs how types may evolve while staying wire-compatible. DDS-Security 1.2 plugs in authentication, access control, cryptography and logging. DDS-RPC, DDS-XRCE, DDS-XML and DDS-WEB are profile extensions for request-reply, constrained devices, XML-driven config and REST access.
Each spec is independently versioned and independently implementable. ZeroDDS implements all eight as separate crates so you can pick exactly what you need — every layer is opt-in.
Why — every layer, end-to-end
Two reasons we implement every OMG layer. First, lock-in avoidance: a partial DDS implementation forces you back to a vendor product the moment you need a profile we skipped. With every layer covered, you can stay inside the standard for every use case.
Second, audit transparency: a spec-coverage report per layer lets compliance teams trace every requirement to a file and a test. There is no 'we kind of support X' shadow — either the coverage report says ✓ or it says open.
Concretely, what every layer gets you: DCPS = a stable application API; RTPS = native-RTPS vendor interop; XTypes = type evolution without breaking readers; DDS-Security = production-grade auth and crypto; DDS-RPC = request-reply over the same bus; DDS-XRCE = sub-1 KB participants on MCUs; DDS-XML = the same config format your other DDS deployments use; DDS-WEB = browsers and admin tools without a DDS client.
What we built
Every OMG core spec maps to one or more crates in the workspace. Click the spec-coverage report to see requirement-by-requirement status.
| Layer / spec | Crates | External spec | Coverage report | Status |
|---|---|---|---|---|
| DCPS · DDS 1.4 | dcps · dcps-async · qos · types · sql-filter |
DDS 1.4 → | dds-dcps-1.4 → | ✓ RC3 |
| RTPS 2.5 wire | rtps · foundation |
DDSI-RTPS 2.5 → | ddsi-rtps-2.5 → | ✓ RC3 |
| XTypes 1.3 | dcps · types (integrated) |
DDS-XTypes 1.3 → | dds-xtypes-1.3 → | ✓ RC3 |
| DDS-Security 1.2 | security · security-crypto · security-keyexchange · security-logging · security-permissions · security-pki · security-rtps · security-runtime |
DDS-Security 1.2 → | dds-security-1.2 → | ✓ RC3 |
| DDS-RPC 1.0 | rpc |
DDS-RPC 1.0 → | dds-rpc-1.0 → | ✓ RC3 |
| DDS-XRCE 1.0 | xrce · xrce-agent · xrce-client |
DDS-XRCE 1.0 → | dds-xrce-1.0 → | ✓ RC3 |
| DDS-XML 1.0 | xml |
DDS-XML 1.0 → | dds-xml-1.0 → | ✓ RC3 |
| DDS-WEB 1.0 | web |
DDS-WEB 1.0 → | dds-web-1.0 → | ✓ RC3 |
| Discovery (SPDP / SEDP) | discovery |
part of DDSI-RTPS 2.5 §8.5 | discovery → | ✓ RC3 |
| Transport plug-ins | transport · transport-udp · transport-tcp · transport-shm · transport-tsn · transport-uds |
RTPS-PSM bindings + iceoryx2 (shared memory) | tcp-transport-1.0 → | ✓ RC3 |
How — configure the layers
Most layers are config-driven. Pick a QoS profile, pick a discovery profile, pick which transports to enable, and the rest is wiring.
QoS configuration
Twenty-two QoS policies, configurable per topic, per writer, per reader. Five tested profiles ship for the common cases (best-effort streaming, reliable telemetry, durable history, deadline-bound control, transient command).
Discovery configuration
SPDP for participant announce on a multicast group, SEDP for endpoint metadata, static discovery for locked-down deployments. Multicast vs unicast trade-offs documented per topology.
Security configuration
Plug in Authentication, Access Control, Cryptography and Logging via governance.xml + permissions.xml. TLS via rustls on TCP transports.
Transport configuration
Enable UDP, TCP, TLS, shared memory (iceoryx2-compatible), TSN, or Unix-domain sockets — independently per participant. Buffer sizes, busy-poll, RT-pinning all documented.