zenoh

zenoh (pronounced “zeno”) is the Rust reference implementation of the Eclipse Zenoh protocol, a unified data-in-motion, data-at-rest, and computation stack designed to run efficiently from cloud servers down to microcontrollers. Rather than treating publish/subscribe, query/reply, and storage as separate systems bolted together, zenoh blends them into one wire protocol addressed through hierarchical, wildcard-capable key expressions like robot/sensor/*.

The crate exposes a Session-centric async API: publishers and subscribers for pub/sub, queriers and queryables for request/reply, plus liveliness tokens and a matching API so publishers can detect whether anyone is listening before sending data. It ships pluggable transports (TCP, UDP, QUIC, TLS, WebSocket, serial, Unix sockets, vsock) and an optional shared-memory transport for zero-copy IPC on the same host, all negotiated automatically as peers form a mesh, star, or clique topology.

A companion zenohd router binary and a plugin system (REST gateway, storage-manager backends) let teams stand up Zenoh infrastructure without embedding the library directly, while zenoh-ext adds advanced delivery guarantees and cross-language serialization on top of the core crate. Official bindings extend the same protocol to C, C++, Python, Kotlin, Java, TypeScript, and Go, making Rust-authored zenoh services interoperable with those runtimes out of the box.

What You Get

• A Session API with publishers, subscribers, queriers, and queryables built on hierarchical wildcard key expressions
• Pluggable transports — TCP, UDP, QUIC, TLS, WebSocket, serial, Unix sockets, vsock — negotiated automatically between peers
• Optional shared-memory transport for zero-copy publish/subscribe between processes on the same host
• Liveliness tokens and a matching API so publishers can detect interested subscribers before sending
• A standalone zenohd router with a plugin system (REST gateway, storage-manager backends) for running Zenoh infrastructure outside the application process
• The zenoh-ext crate adding advanced delivery guarantees (AdvancedPublisher/AdvancedSubscriber) and cross-binding serialization

Common Use Cases

• Robotics and ROS2 integration where nodes need low-latency pub/sub across varied network links, including serial and shared memory
• IoT and edge-computing fleets that must move data between constrained devices, gateways, and cloud with one protocol instead of separate messaging and storage systems
• Distributed storage and query systems where consumers can subscribe to live updates and also query historical/at-rest data through the same key-expression namespace
• Geo-distributed applications that need to bridge peers across TCP, QUIC, and WebSocket links without hand-rolling protocol translation
• Polyglot systems combining Rust services with Python, C++, Java, Kotlin, TypeScript, or Go clients that all speak the same Zenoh wire protocol

Under The Hood

Architecture zenoh is organized as a Cargo workspace where the zenoh crate is the public-facing reference implementation sitting atop internal commons/ crates (zenoh-protocol, zenoh-transport-adjacent codecs, zenoh-config, zenoh-runtime) whose APIs are explicitly marked unstable. The public surface centers on Session, opened via zenoh::open(config), from which Publisher, Subscriber, Queryable, and Querier objects are declared through a consistent builder pattern (e.g. session.declare_publisher(...)) resolved either by awaiting in async contexts or calling .wait() synchronously. Transport negotiation and routing live in separate io/zenoh-link* and io/zenoh-transport crates, cleanly decoupling wire-level concerns from the session API, while zenohd and plugins/ compose the same crates into a standalone router process — so the core session logic is exercised identically whether embedded in an application or run out-of-process.

Tech Stack The project is pure Rust (99.96% of the codebase) on the 2021 edition, built with a workspace of ~30 member crates under a single [workspace.package] block for shared metadata. It layers async I/O for its transport crates (tcp, udp, quic, tls, ws, serial, unixpipe, vsock, quic_datagram) and an optional shared-memory feature gating a dedicated zenoh-shm crate for zero-copy IPC. Feature flags (auth_pubkey, auth_usrpwd, transport_*, plugins, runtime_plugins) let consumers opt into only the transports and capabilities they need, keeping default builds lean while zenohd opts into the full set for router deployments.

Code Quality The repository carries a dedicated zenoh/tests/ directory with dozens of integration test files (acl, authentication, connectivity, liveliness, matching, interceptors, low-pass filtering, and more) alongside a .config/nextest.toml, indicating a nextest-based CI test runner rather than ad hoc cargo test. clippy.toml, rustfmt.toml, and deny.toml enforce lint, formatting, and dependency-licensing/advisory policy respectively, and GitHub Actions workflows cover CI, scheduled fuzzing, and release automation. Public API surfaces (session, publisher, subscriber, query) carry extensive /// doc comments with runnable examples, and errors are represented through a dedicated zenoh-result crate rather than ad hoc panics.

API Design The API favors a small number of consistent verbs — declare_publisher, declare_subscriber, declare_queryable, get — all returning builders that resolve via .await or .wait(), so async and sync callers share one mental model. Consumers can choose between callback-based and channel-based delivery (FIFO by default, pluggable via .with()) without changing how they construct publishers or subscribers, and the prelude module offers a single low-friction import path for common entry points, keeping the boilerplate to open a session and publish/subscribe to a handful of lines as shown in the crate-level doc examples.