Rust SIG Meeting - 2026-06-23

[PLeVasseur]

Hey folks 👋 welcome to our 12th meeting of 2026.

Rust SIG Meeting 2026-06-23

Agenda

1. Solicitation of notetaker
   • Pete LeVasseur
2. Rust Watercooler Chat Topic: Zenoh + Rust + Microcontrollers = zenoh-nostd; Angelo Corsaro, Eclipse Zenoh
3. Review GitHub repo content and discuss how to enrich it (Pete)
   1. Issues
   2. Discussions are now active. The SIG previously agreed to take meeting notes there.
4. Office hours: Rust + Automotive questions — come chat (All)
5. Discuss upcoming events / news related to Rust & Automotive (All)
6. Meeting close

Check-in area

We had roughly 13 people present at peak attendance, including those listed below.

• @PLeVasseur
• @bharatGoswami8
• @odra
• @adrianaioanei
• @cpetig

Housekeeping

• Document space: https://drive.google.com/drive/folders/1Ub0qTLKvTFilPC9TFVEdTyWn_9qJ-vYD?usp=drive_link
• GitHub repo: https://github.com/rust-sig/rust-sig
• Eclipse SDV Slack channel: #rust-sig

Tasks / action items

• No explicit action items were captured in the source notes.

Meeting Minutes

Zenoh + Rust + Microcontrollers = zenoh-nostd; Angelo Corsaro - Eclipse Zenoh

Slides are available from the chat here:

2026.06.23-zenoh-nostd.pdf

Quick Zenoh intro

Angelo started Eclipse Zenoh and acts as Eclipse Project lead.

Smart-city work in the late '10s pushed the Cloud-to-Device Continuum pains into the open, which is what gave rise to Zenoh.

Very few (no?) protocols at the time could run from a microcontroller all the way up to the cloud.

Distributed queries were a key piece too. Keeping data local to some storage is a practical requirement in a lot of places, and that's hard to solve with classic databases.

The need was emerging and cut across industries — IoT, medical devices, automotive.

The Zenoh Protocol is the same whether you're on a microcontroller or in the cloud. Other middlewares/protocols split here: DDS uses DDS-XRCE on constrained devices, MQTT differs too. Zenoh gives unified, location-transparent abstractions for high-performance pub/sub and distributed queries across heterogeneous systems.

• built-in support for zero-copy and shared memory
  • shared-memory provider model: POSIX shared memory is one provider, but you can plug in others (e.g. GPU memory)
• designed for performance and power efficiency

The Distributed Computing Platform

• Zenoh is a Protocol, plus implementations of it, plus a distributed computing platform layered on top that extends the Zenoh primitives.
• The platform adds: generalized group membership, internet-scale storage alignment, end-to-end reliability, security, storage & protocol plugins, monitoring and management.

Diagram & Example (the louvre temperature-sensor walkthrough)

• A database in Zenoh is just a queryable + subscriber (subscriber captures the keyset into storage, queryable serves it back).
• A Publisher doesn't really exist at the Protocol level — it's sugar at the implementation level.
• Wildcards in key expressions: * matches a single chunk, ** matches across multiple. So louvre/**/sensor/temp subscribes across the whole subtree.

Introductory Example

• Both sync and async APIs exist in the full Rust implementation.
• Opening a session, subscribing, and publishing are all simple to get started with.
• Publication is "sugar" — you can put data straight onto a keyset with .put(/* keyexpr */, /* value */).

Running queries

• The Zenoh Protocol question is: "what's the closest place to route this query to that can understand the predicates and provide the information?"
• Uses breadcrumbs to find the way back to the querier.
• The querier is completely unaware of where the data actually comes from.

Disambiguating RPC from Querying

• RPC is inherently client-server-centric: one request, one response.
• Query does a set-cover over the key expression — which set of sets (a potential superset of the query) among queryables, and in routing terms where to direct it.
  • Far more generic.
  • Location transparent.
  • Zenoh doesn't implement databases, but gives you the "glue" to expose Queryables: sqlite, etc. all possible.
  • Opens the door to a map-reduce mechanism.

Protocol Stack

• Runs on anything that can behave like a Data Link Layer — a pipe that moves data A → B; best-effort or one-shot is fine.
• Spans transport down to data link, plus OS IPC. Currently: TCP/IP, UDP/IP, QUIC, Serial, Bluetooth, OpenThreadX, Unix Domain Sockets, Pipes, Shared Memory.
• 7 bytes minimal overhead.

Any Topology

• Peer-to-peer: clique and mesh topologies.
• Routed: routers forward data to and from peers and clients.
• Brokered: clients talk through a router or a peer.

Topology in Perspective

• DDS: peer-to-peer only.
• MQTT: requires a broker.
• Zenoh: any of the above, and mixes them — peers, routers, and clients in the same system.

Implementations

Original implementation was written in OCaml and was deployed into production. One reason for the Rust rewrite: the biggest Zenoh user needed 24/7 support, and there was a lack of OCaml programmers to staff it.

It stayed in OCaml up to 2017. OCaml runtimes were single-threaded back then — seen as a large limitation. (Situation has since improved in OCaml.)

A user asked them to write it in Go; the structure and lack of expressivity in Go was tough to accept.

Rust was explored for Zenoh in 2015 but didn't feel quite there yet — the borrow checker at that point was seen as too immature.

Revisiting in 2017 landed on more-or-less what became the Rust 2018 edition. Async landing was a positive. And there was the eventual promise of putting Rust on microcontrollers, e.g. STM32.

Eclipse Zenoh (in the Eclipse SDV WG)

• eclipse-zenoh/zenoh — pure-Rust reference implementation of the protocol, with APIs for all the mainstream languages (C, C++, C#, Go, Kotlin, Java, Elixir, Python, TypeScript, Dart, ...).
• eclipse-zenoh/zenoh-pico — C implementation targeting embedded; implements the full protocol except mesh routing. Exposes C and C++ APIs, essentially identical to the C/C++ API on zenoh.
• Convention: capital-Z Zenoh is the Protocol, lowercase zenoh is the implementation.
• zenoh and zenoh-pico are more-or-less API compatible — you can write C or C++ and compile against either.

zenoh-nostd

Two buckets of motivation: the obvious and the less obvious.

Obvious — Rust + microcontroller. Memory-safe concurrent code on embedded MCUs. You can do it in C or C++, but you have to bring the discipline yourself. Rust requires and enforces that discipline.

Less obvious — forward-looking. Wanted a clean rewrite of the protocol that could be shared between std and no-std. A more manageable stack to play with protocol innovations. And to prepare the road for Zenoh 2.0.0 (the 2nd version of the Zenoh Protocol).

Question: "No alloc, so do we fix sizes in zenoh-nostd?"

• Yes, that's done.
• You need to know things like the subscriber maximum and queue size — everything can be statically configured.
• You can opt into having alloc.
• A no-std broker on a microcontroller makes for interesting applications: drivers talking serial, all routed through the broker.

Question: "Didn't you hit issues introducing the no_std and async functionality?"

• Some of the callback handling was tricky, but there's a nice crate someone made that helps with this.
• Handling the lifetimes is the hardest/trickiest part.

Protocol Implementation

Protocol Implementation Rewrite

• zenoh's protocol implementation has grown convoluted, more complex than it needs to be. Hard to understand, and as a result hard to maintain.
• The goal for zenoh-nostd was a clean, streamlined protocol implementation to carry forward for all Rust implementations of Zenoh.

Zenoh Protocol in zenoh

• Lives in commons/zenoh-codec and commons/zenoh-protocol.
• zenoh-codec: 6650 SLOC. zenoh-protocol: 6334 SLOC. Total 12984 SLOC (implementation only, not counting tests & co).

Zenoh Protocol in zenoh-nostd

• Lives in zenoh-proto, leaning on procedural macros from zenoh-derive.
• zenoh-derive: 2088 SLOC. zenoh-proto: 2721 SLOC. Total 4809 SLOC.
• That's ~1/3 of the SLOC of the zenoh protocol implementation. Interest messages are missing, but those won't add a huge number of SLOC. Scouting is also missing — though that's not technically part of the Zenoh Protocol, it's just a bootstrapping mechanism.

Messages

• Implemented set is the bulk of the protocol: transport messages (InitSyn/InitAck, OpenSyn/OpenAck, KeepAlive, Close) and network messages (Frame, Declare, Push → Put, Request → Query, Response → Reply / Err, ResponseFinal).
• What's missing is the interest messages. Scouting too, but again that's bootstrapping rather than the protocol proper.

zenoh-nostd Architecture

• Separates platform-independent from platform-specific aspects.
• Assumes Embassy as the async framework.
• Concrete platforms live under zenoh-nostd/platform.
• zenoh-sansio is a "Sans I/O" implementation of the Zenoh Protocol State Machine — the protocol engine written without I/O. Decoupling from I/O makes properties much easier to verify; common practice in FP circles.
• Layering, top down: api/ (user-facing: Session/Broker, Pub/Sub/Queryable/Querier, Sample/Query/Response, callbacks) → io/ (driver rx/tx loop, lease timers, link traits) → zenoh-sansio (handshake FSM, Tx batch/frame, Rx decode) and platforms/* (concrete I/O: std, embassy, wasm) → zenoh-proto (wire format).

Dependencies

• Bottom of the graph is the root zenoh-examples package, which pulls in the platform crates zenoh-std (std feature), zenoh-embassy (esp32s3 feature), and zenoh-wasm (wasm feature).
• Those depend on zenoh-nostd (API + io), which sits on zenoh-sansio (sans-I/O transport), which sits on zenoh-proto (messages + codecs), which uses zenoh-derive (proc-macros).
• zenoh-nostd provides the public API and the orchestration.

APIs

• Rust async API across the board.
• Three target shapes:
  • Microcontrollers (Embassy): ultra-low footprint, async-first, energy efficient.
  • Any std platform: servers/desktops/edge, high performance, secure by design.
  • WASM: browser & edge runtimes, plus a TypeScript API.
• no_std, no_alloc, small footprint.

P2P Latency

• zenoh: ~21µs for an 8-byte payload (measured on his laptop).
• zenoh-nostd: ~13–14µs for the same payload on the same machine.
• zenoh-nostd lands at roughly 2/3 the latency of zenoh on the same hardware.

Throughput

• zenoh: ~12.5M msg/s for an 8-byte payload — zenoh does automatic batching.
• zenoh-nostd: ~600K msg/s for an 8-byte payload. No batching yet, so that's a decent number on its own. User-level batching of put on a session already reaches ~10M msg/s in experiments; proper batching will be opt-in via API.

Latest on Zenoh

• New Wireshark dissector. Written in Lua to skip the install-deps/compile dance. Gives very detailed breakdowns of Zenoh messages. Some WebSocket support too.
• Draft protocol specification now available at spec.zenoh.io (covers Zenoh 1.0.0). Work in progress; Creative Commons.
• Draft Zenoh Book started to ease onboarding for new users — already has some solid material.
• Web demo: in-browser publishers / subscribers / queryables / get, talking to a router.

Question: "What esp32-s3-specific features are there (shown as a dependency on the previous slide)?"

• Some specifics in there for Embassy to function on the platform.
• Behind a feature flag; opt into it to bootstrap and start on the platform.

Question: "I see the strength of Zenoh for distributed systems. Compared to e.g. Embassy's native pub/sub channel implementation — is there still an edge to using Zenoh on a single-core application where I just want different software units to talk to each other?"

• If you're doing that, enable shared memory.
• Two ways to do shared memory: (1) payloads over ~2KB go on shared memory; (2) use a shared-memory provider.

Note (@cpetig): "If you ever want to rewrite the dissector in Rust, this older example might come in handy (I did similar things 3 years ago, also for a complex protocol): https://github.com/cpetig/wireshark-veloren/blob/main/rust/src/lib.rs"

Credits

• Enzo Le Van (final-year student at CentraleSupélec) did a lot of the heavy lifting over a 6-month collaboration.

Closing

• Zenoh is both a protocol and a distributed computing framework, already used as a foundation in robotics, automation, medical, and beyond.
• zenoh-nostd paves the road for Zenoh + Rust on microcontrollers and gives a cleaner base for trying out protocol innovations and evolutions.

Q&A notes

Audience questions were captured inline with the part of the talk they came up in (see the talk notes above).

Recent events / things coming up for Rust

No recent events or upcoming items were captured in the source notes.

Requested topics

No requested topics were captured in the source notes.

Material

• zenoh-nostd: https://github.com/eclipse-zenoh/zenoh-nostd
• Zenoh Protocol Specification (draft): https://spec.zenoh.io
• Draft Zenoh Book: https://corsaro.me/en/zenoh/book/
• zenoh: https://github.com/eclipse-zenoh/zenoh
• zenoh-pico: https://github.com/eclipse-zenoh/zenoh-pico

[bharatGoswami8]

@bharatGoswami8

[odra]

@odra

[adrianaioanei]

@adrianaioanei

[cpetig]

@cpetig