Subsystem · Protocol bridges

Protocol bridges

First-class bridge daemons between DDS topics and the ten protocols you already deploy. Wire-spec conformant on both sides, deterministic QoS mapping, no silent translation losses.

Learn

Learn — what is a protocol bridge?

A bridge daemon sits between a DDS bus and a non-DDS protocol (MQTT, AMQP, CoAP, WebSocket, gRPC, ROS 2, etc.). For every DDS topic it cares about, it has a peer endpoint in the other protocol — and it forwards samples in both directions, translating sample state, payload encoding and delivery semantics.

The hard part is not the forwarding — it is the semantic translation. MQTT QoS 0 / 1 / 2 has to map onto DDS Reliability + Durability without surprising either side. AMQP's delivery state machine has to match DDS' sample state. CoAP's observe-mode needs an obvious mapping to DDS subscriptions. Each bridge is a small protocol-spec implementation of its own.

ZeroDDS treats every bridge as a first-class crate with its own spec-coverage report, its own conformance tests, and its own QoS-translation matrix. No protocol gets a 'good enough' translation that breaks in production.

Staying inside DDS — across domains, topics, QoS profiles or partitions — is a different job, handled by the in-DDS routing service (zerodds-router), the ZeroDDS equivalent of the RTI Routing Service.

Why

Why — first-class crates, not side projects

Most DDS vendors treat bridges as optional add-ons — a wrapper around the official client, often unmaintained, often missing edge cases (QoS-0 with retained-messages, AMQP message annotations, CoAP block-wise transfers). The result: production teams hit a bridge bug, file a ticket, wait months.

ZeroDDS makes every bridge a workspace crate next to the core. Same CI, same release cycle, same audit standard. Each bridge ships with a conformance test against its protocol's spec — MQTT 5.0, AMQP 1.0, CoAP RFC 7252, WebSocket RFC 6455, gRPC, ROS 2 REP-2007/2009.

First-class also means deterministic semantics. Every QoS-mapping decision is documented (with a rationale) in the bridge's README. When DDS Reliable+TransientLocal meets MQTT, the bridge maps that to MQTT QoS 1 + retained — and a CI test verifies the result against a real MQTT broker. No surprises.

Operationally, the bridges are independent daemons. You can run one bridge per protocol on the same host as the DDS participants, or scale them out on dedicated nodes. They observe DDS Discovery natively, so adding a new topic requires no bridge restart.

What

What we built

Ten protocol bridges plus the full CORBA family. Each crate is RC3-ready with a conformance report and ABI-stable config schema.

Crate Maps DDS ↔ External spec
mqtt-bridge MQTT 5.0 OASIS MQTT 5.0 — QoS 0/1/2, retained, sessions, will-messages. Topic alias support.
amqp-bridge AMQP 1.0 OASIS AMQP 1.0 — queues, exchanges, message annotations, delivery state. amqp-endpoint provides the low-level transport.
coap-bridge CoAP IETF RFC 7252 (+ RFC 7641 observe, RFC 7959 block-wise transfer).
xrce-agent DDS-XRCE OMG DDS-XRCE 1.0 — bridges resource-constrained clients (microcontrollers over serial/UDP) into the DDS data space.
websocket-bridge WebSocket IETF RFC 6455 + ZeroDDS framing for DDS samples. TLS via rustls.
grpc-bridge gRPC HTTP/2 + Protobuf 3. Server, client and bidi-streaming. DDS-RPC also flows through this bridge.
rmw-zerodds-shim ROS 2 RMW ROS 2 RMW interface (REP-2007). rmw-zerodds-shim is a drop-in replacement for rmw_cyclonedds_cpp.
zenoh-bridge Zenoh Eclipse Zenoh wire protocol. Useful for geo-distributed routing scenarios.
opcua-gateway OPC UA OPC UA — industrial automation. Full OMG DDS-OPCUA 1.0 gateway: type-system + AddressSpace mapping (DDS domain → OPC UA nodes) and Historical Access — all four conformance points.
zerodds-soap SOAP / Web ServicesWSDL-driven SOAP gateway for legacy enterprise integrations.
bridge-security Bridge securityShared utilities used by every bridge — TLS via rustls, identity policy, audit logging.

Spec coverage — per bridge

Each bridge points to the external protocol spec it implements, its source on GitHub, and the conformance tests we run in CI.

Bridge External spec Our spec doc Implementation Tests Status
MQTT 5.0 MQTT 5.0 zerodds-mqtt-bridge-1.0 → mqtt-bridge tests ✓ RC3
MQTT 3.1.1 MQTT 3.1.1 mqtt-3.1.1 → mqtt-bridge (version-aware codec) tests ✓ RC3
AMQP 1.0 AMQP 1.0 zerodds-amqp-bridge-daemon-1.0 → amqp-bridge tests ✓ RC3
AMQP 0.9.1 AMQP 0.9.1 amqp-0-9-1 → amqp-0-9-1 tests ✓ RC3
CoAP RFC 7252 zerodds-coap-bridge-1.0 → coap-bridge tests ✓ RC3
DDS-XRCE OMG DDS-XRCE 1.0 dds-xrce-1.0 → xrce-agent tests ✓ RC3
WebSocket RFC 6455 zerodds-ws-bridge-1.0 → websocket-bridge tests ✓ RC3
gRPC grpc.io zerodds-grpc-bridge-1.0 → grpc-bridge tests ✓ RC3
ROS 2 RMW REP-2007 zerodds-ros2-bridge-1.0 → rmw-zerodds-shim tests ✓ RC3
CORBA / IIOP CORBA 3.3 zerodds-corba-bridge-1.0 → CORBA subsystem → tests ✓ RC3
Zenoh zenoh.io spec pending zenoh-bridge tests ✓ RC3
OPC UA OPC UA spec pending opcua-gateway tests ◐ partial
SOAP W3C SOAP spec pending zerodds-soap tests ✓ RC3
How

How — running a bridge

Every bridge is a single binary. Configure once via TOML or environment variables, run alongside your DDS participants, observe discovery natively.

Topic mapping & QoS

Each bridge ships a topic-mapping matrix: how DDS topic names map to external topics/queues/paths, how DDS QoS maps to external QoS, how sample state maps to external delivery state. The matrices are part of the crate README.

Security across bridges

All bridges use the bridge-security crate for TLS, identity assertion and audit logging. Configuration is consistent across protocols — one PKI setup covers MQTT, AMQP, gRPC and WebSocket TLS in the same way.

Security plugin chain →

Per-bridge pointers

MQTT

MQTT 5.0 broker — connect to any MQTT 5.0 broker (Mosquitto, EMQX, HiveMQ, AWS IoT). Topic alias + retained-message support, session expiry, will-messages.

zerodds-mqtt-bridge --broker tcp://broker:1883 --domain 0
AMQP

AMQP 1.0 broker — RabbitMQ, Solace, ActiveMQ Artemis, Azure Service Bus. Queue and exchange topology, message annotations, link credit.

zerodds-amqp-bridge --uri amqp://rabbit:5672 --domain 0
CoAP

CoAP — constrained-device endpoints (RFC 7252). Observe-mode (RFC 7641) maps to DDS subscriptions. Block-wise transfer (RFC 7959) for large payloads.

zerodds-coap-bridge --listen coap://0.0.0.0:5683
WebSocket

WebSocket — browsers and Node.js clients. WebSocket framing per RFC 6455, DDS sample framing on top. TLS via rustls.

zerodds-websocket-bridge --listen 0.0.0.0:8765
gRPC

gRPC — wraps DDS topics in server-streaming and bidi-streaming calls. DDS-RPC interfaces also flow through this bridge.

zerodds-grpc-bridge --listen 0.0.0.0:50051
ROS 2

ROS 2 — drop-in RMW (ROS Middleware) replacement for rmw_cyclonedds_cpp. No application changes needed.

export RMW_IMPLEMENTATION=rmw_zerodds
Zenoh

Zenoh — Eclipse Zenoh wire protocol. Useful for geo-distributed routing where neither DDS multicast nor MQTT brokers fit.

zerodds-zenoh-bridge --listen tcp/0.0.0.0:7447
OPC UA

OPC UA — industrial-automation gateway (OMG DDS-OPCUA 1.0). Type-system + AddressSpace mapping and Historical Access; pairs with the full OPC UA PubSub (Part 14) and client/server stacks.

zerodds-opcua-gateway --listen opc.tcp://0.0.0.0:4840
SOAP

SOAP — WSDL-driven gateway for legacy enterprise web services. Authenticated via CSIv2 or PKI.

zerodds-soap --wsdl service.wsdl --listen 0.0.0.0:8080