Per-RMW Feature Matrix
One table per question the capability pages used to answer in
contradictory prose. Derived from the backend sources — the two
C vtables (vtable.cpp,
vtable.c) and the zenoh shim’s trait
overrides — so a backend gaining or losing a slot moves this page in
the same commit or fails the gate.
wired = the backend implements it. — = not wired: the runtime
surfaces UNSUPPORTED or falls back where a fallback exists (the
vtable comments name which). The rows below the parity marker are
the phase-376 W4 surface — slots declared in the ABI whose backend
wiring is the in-flight campaign; all-dash rows there mean
declared, not yet wired anywhere, and they flip automatically as
backends land implementations.
Session / entity capabilities
| Capability | Zenoh | XRCE-DDS | Cyclone DDS |
|---|---|---|---|
| Publish / subscribe | wired | wired | wired |
| Services (server side) | wired | wired | wired |
| Service clients | wired | wired | wired |
| Server-availability probe | wired | — | wired |
| Status events (deadline / liveliness / lost) | wired | — | — |
| Manual liveliness assert | wired | — | wired |
Event-driven wake (set_wake_callback) | wired | — | wired |
Deadline hint (next_deadline_ms) | wired | — | — |
| Zero-copy loan API | — | — | — |
Batch receive (take_sequence) | wired | — | wired |
| Streamed publish | wired | wired | — |
| Connectivity ping | wired | wired | — |
| Identity / feature probe | — | — | — |
| Publisher GID / matched counts | — | — | wired |
| Actual-QoS read-back | wired | — | wired |
| Wait-for-acked | — | — | — |
| Take-with-info | wired | — | wired |
| Graph introspection (names/types/counts) | wired | — | wired |
Node-layer features
These live in nros-node on top of pub/sub + services — they are
not backend slots, so the rule, not a vtable, decides the row:
| Feature | Zenoh | XRCE-DDS | Cyclone DDS | Rule |
|---|---|---|---|---|
| Actions | yes | yes | untested | Built in nros-node on pub/sub + services. Cyclone has both since service.cpp, but no action example runs on it in CI — see known limitations. |
| Parameters (+ param services) | yes | yes | yes | Node-layer services (RFC-0004); available wherever services are. |
| Lifecycle (REP-2002) | yes | yes | yes | Node-layer state machine + services (lifecycle-services feature). |
QoS policies
A backend advertises the policies it can enforce via
supported_qos_policies(); requesting an unadvertised policy fails
entity creation loudly (INCOMPATIBLE_QOS) — no silent
downgrade. Per-policy semantics: RMW vs upstream §7.
| Policy | Zenoh | XRCE-DDS / Cyclone DDS (via C ABI) ¹ |
|---|---|---|
CORE | ✓ | — |
DURABILITY_TRANSIENT_LOCAL | ✓ | — |
DEADLINE | ✓ | — |
LIFESPAN | ✓ | — |
LIVELINESS_AUTOMATIC | ✓ | — |
LIVELINESS_MANUAL_BY_TOPIC | ✓ | — |
LIVELINESS_MANUAL_BY_NODE | — | — |
LIVELINESS_LEASE | ✓ | — |
AVOID_ROS_NAMESPACE_CONVENTIONS | — | — |
¹ The C-ABI backends’ mask is asserted by the runtime shim
(packages/rmw/cffi/src/lib.rs), not reported by the backend — the
vtable has no supported_qos_policies slot yet (TODO 115.K.2.x).
Treat the column as the runtime’s assumption; the backend’s own
enforcement happens at entity creation.
Related
- Choosing an RMW Backend — the decision tree
- Backend Reference — architecture, footprint, transports per backend
- Support Status — versions, pins, and CI tiers