DDS simulator

Connect

The bridge binds the first free pair of ports of the standard mapping — 7410 for discovery and 7411 for data on domain 0, then 7412 and 7413, and so on — joins the discovery multicast group on every interface it can, and carries each datagram to the hub and back. The hub announces itself to the participants it can reach on your computer and answers the ones that announce themselves. The bridge prints what the hub finds and matches, and when a reader or writer does not match, why:

curl -O https://sondahub.com/industrial/bridge.mjs
node bridge.mjs dds

DDS domain 0 · participant 0 · ports 7410 (discovery) and 7411 (data) · group 239.255.0.1:7400
→ wss://api.sondahub.com/dds — a client on this computer finds it at the peer 127.0.0.1 or by multicast
the hub is participant c3ff6f8d.3fb2ad77.3da88626 on domain 0
found participant 01106bff.9963e1f8.20b0bbbe — Cyclone DDS — at 127.0.0.1:7412
their reader on rt/chatter: matched — reliable, volatile
their writer on rt/cmd_vel: matched — the hub reads it, best effort
their reader on PlantReadings: not matched — type Reading, the hub's is plant::Reading

In a DDS client

Start the bridge first. Then point the client’s discovery at it: a unicast peer at 127.0.0.1 finds it on its own (DDS tries the ports of the first participant indexes; if the bridge says it took participant 2, the port is 7414), or multicast on the loopback or any interface the bridge joined. Use domain 0 unless you gave the bridge another one. Declare the types from sondahub-dds.idl exactly as they are — DDS matches types by their full names — and subscribe or publish.

In LockFlare Sonda: Discovery Peers only with the peer 127.0.0.1, the loopback interface (lo0 on macOS), and the types from the IDL file.

Topics

The robot, as ROS 2 sees it

A small differential-drive robot in an 8 × 8 m room with a pillar and a crate. It drives itself, turning away from what its lidar sees, until something arrives on rt/cmd_vel.

The plant, as plain DDS

A tank filled through an inlet valve and pumped down through a filter: keyed topics, one instance per sensor, alarm and setpoint.

Types

All of them, with what they use, in one file: sondahub-dds.idl. The ROS 2 types keep their DDS names — geometry_msgs::msg::dds_::Twist_ — and their fields as ROS 2 defines them. The plant’s keyed types bound their key strings to 11 characters, so the key fits the 16 bytes of an RTPS key hash as it is.

module plant {
struct Setpoint {
  @key string<11> name;
  double value;
};
};

The hub writes XCDR1 (encapsulation CDR_LE). It reads XCDR1 and XCDR2 — final or appendable types, either byte order; mutable types (parameter-list encodings) are not read.

QoS and matching

A match needs the same topic name and the same type name (no type information is exchanged), a durability the hub can give (volatile or transient-local; transient and persistent readers are refused), the default partition, and a data representation both sides take. A late transient-local reader gets the last ten samples of each instance before the live ones.

The plant

The pump starts when the tank reaches 4 m and stops at 1 m; between them, the inlet fills it and the pump empties it, about a twelve-minute cycle as it starts. The filter clogs on its own and backwashes every five minutes, raising and clearing FILTER-DP.

PlantReadings

PlantAlarms

PlantSetpoints

JSON, from any WebSocket client

A text message is a request: subscribe to the topics the hub writes (the present value of each instance comes first, as a transient-local reader gets it), publish to the ones it reads, or list the topics with their types and IDL. Topics answer to their DDS or their ROS 2 names.

{"subscribe":["rt/chatter","PlantAlarms"]}
{"subscribe":"*","cdr":true}             # every topic, payloads in hex
{"publish":"/cmd_vel","sample":{"linear":{"x":0.3},"angular":{"z":0.5}}}
{"publish":"PlantSetpoints","sample":{"name":"PUMP-SPEED","value":1500}}
{"unsubscribe":"*"}
{"topics":true}

{"topic":"PlantReadings","seq":214,"time":"2026-10-07T09:04:00.165Z",
 "sample":{"sensor":"TANK-LEVEL","value":3.629,"unit":"m"}}

The bridge, on the wire

For anyone writing a bridge of their own: it opens wss://api.sondahub.com/dds and says hello in text — {"bridge":"dds","version":1,"domain":0,"participant":0,"meta":7410,"user":7411,"addresses":["127.0.0.1",…],"multicast":true} — then each datagram is a binary message: a byte for the port (0 discovery, 1 data, 2 the multicast group), the IPv4 address and the port (big-endian) it came from or goes to, and the datagram. The hub’s text messages are {"log":…} lines.

Also on sondahub

Fake REST API · Public GraphQL API · gRPC-Web & Connect · SOAP test server · JSON-RPC & XML-RPC · OData test server · FHIR test server · Socket.IO test server · WebSocket test server · SSE test server · Public MQTT broker · MCP test server · MCP OAuth test server · Writes that persist · OpenAPI mock server · Webhook tester · Chaos and rate limits · SAML test IdP and SP · SCIM 2.0 test server · OAuth 2.0 test server · Auth test endpoints · HTTP test endpoints · Fake JSON data · Stripe sandbox · Twilio sandbox · SendGrid sandbox · Authorize.net sandbox · OpenAI sandbox · Anthropic sandbox · AWS Secrets Manager sandbox · Azure Key Vault sandbox · Google Secret Manager sandbox · 1Password Connect sandbox · Doppler sandbox · Infisical sandbox · OPC UA test server · Modbus TCP simulator · HART-IP simulator

The mock APIs themselves: fake e-commerce API, fake IoT API, fake banking API, fake social media API, fake helpdesk API, fake flight booking API, fake user directory API. Built as the playground for LockFlare Sonda, the API client that lives on your computer.