Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Advanced Zenoh Tutorial -- Part IV

Advanced Zenoh Tutorial -- Part IV

This three-part webinar series is designed for developers who want to master Zenoh’s full potential. We’ll cover everything from core concepts to advanced programming techniques, performance tuning, and deployment strategies. The sessions use Rust as the primary language with some complementary examples in Python. Whether you're building robotics systems, telemetry pipelines, or IoT infrastructures—this series will help you unlock the true power of Zenoh.

Avatar for Angelo Corsaro

Angelo Corsaro

June 10, 2025
Tweet

Video

More Decks by Angelo Corsaro

Other Decks in Programming

Transcript

  1. https://github.com/kydos/zsak Zenoh Swiss Army knife (ZSAK) We’ll extensively use ZSAK

    an experimental command line tool designed to learn and experiment with Zenoh
  2. Get It. Build It. Run It $ git clone [email protected]:kydos/zsak.git

    $ cd zsak $ cargo build —release $ ./target/release/zenoh -h
  3. Scouting Scouting is about “discovering” endpoints to bootstrap Zenoh Sessions

    You can con fi gure sessions explicitly, to control the topology of the resulting Zenoh network You can use scouting to automatically establish sessions between discovered Zenoh’s runtime You can mix the two approaches
  4. Multicast Scouting When multicast scouting is enabled, a runtime will

    multicast SCOUT (WHAT) messages with a signature that indicates what it is looking for WHAT can be any combination ROUTER, PEER, CLIENT SCOUT(WHAT) Zi Zj Zk Za Zb Zc
  5. Multicast Scouting Runtime whose kind matches the SCOUT’s WHAT will

    respond with an HELLO(WHATAMI) message including the locators through which it can be reached WHATAMI can be any combination ROUTER, PEER, CLIENT HELLO(WHATAMI) Zi Zj Zk Za Zb Zc HELLO(WHATAMI)
  6. Default Behavior By default Zenoh runtime con fi gured as

    client will try to scout for Router — peers scouting has to be opt-in If nothing is found within a con fi gurable delay, an error is raised Notice that a client needs either a peer of a router to operate in a zenoh network SCOUT(ROUTER) Zi Zj Zk Za Zb Zc Client
  7. Default Behavior By default Zenoh runtime con fi gured as

    peer will try to scout for anything and establish a session with discovered entities Notice that as peer is self su ffi cient, not fi nding anything does not constitute an error SCOUT(ROUTER|PEER) Zi Zj Zk Za Zb Zc Peer
  8. Multicast Scouting Con fi guration This is the default con

    fi guration which can be tuned depending on your needs scouting: { timeout: 3000, delay: 500, multicast: { enabled: true, address: "224.0.0.224:7446", interface: "auto", ttl: 1, autoconnect: { router: [], peer: ["router", "peer"], client: ["router"] }, autoconnect_strategy: { peer: { to_router: "always", t to_peer: "always" } }, listen: true, } }
  9. More Scouting Multicast Scouting works nicely if you are on

    a network that supports UDP multicast But that isn’t always the case. Sometimes multicast is not con fi gured, in other cases it is clearly forbidden, in yet other cases it is not the behavior you want
  10. Gossip Scouting Let’s use an example to illustrate the idea

    behind gossip scouting Assume you have a Zenoh router R and a certain numbers of peers Pi con fi gured with the router locator Also assume default gossip scouting con fi guration for Zenoh Pi Pj Pk R
  11. Gossip Scouting Pi R Pj Locators Pi The peer Pi

    is started and opens a session with R The peer Pj is started and opens a session with R and receives the locators for Pi which make it possible for Pj to establish a session with Pi
  12. Gossip Scouting The peer Pi is started and opens a

    session with R The peer Pj is started and opens a session with R and receives the locators for Pi which make it possible for Pj to establish a session with Pi When Pk comes around and opens a session with R, it gets the locators for and Pi and Pj R Pj Pk Locators Pi ,Pj Pi
  13. Gossip Scouting Con fi guration This is the default con

    fi guration which can be tuned depending on your needs scouting: { gossip: { enabled: true, multihop: false, target: { router: ["router", "peer"], peer: ["router", “peer"]}, autoconnect: { router: [], peer: ["router", "peer"] }, autoconnect_strategy: { peer: { to_router: "always", to_peer: "always" } }, }, },
  14. Putting it all Together For maximum fl exibility, you can

    use at the same time multicast and gossip scouting Ensure to properly leverage the targets to avoid sending unnecessary scouting information. For instance in the example showed before, ideally you would have used: autoconnect: { router: [], peer: ["router"] }
  15. Scouting Recap Scouting is about establishing Zenoh’s network topologies The

    resulting network will be used to route data How and where data is routed is controlled by other mechanisms
  16. Routing Data and Queries The Zenoh protocol is at its

    heart a routing protocol that works on named data The underlying topology de fi nes the constraints on how data and queries will be routed to reach their destination
  17. Declarations Declarations in Zenoh are used to indicate essentially three

    things: - The association of a key expression with a small numerical ID - A Subscription - A Queryable Notice that the association of a key expression with an ID is unique within a session
  18. Declarations — Key Idea Publisher and Queryable declarations are distributed

    over the Zenoh network Zenoh may decides to generalize subscriptions downstream Zenoh may also decide not to propagate them at all (more later)
  19. Declarations — Key Idea Assume we have a series of

    subscribers Let’s see how the declarations may be propagated in the Zenoh network To keep the intuition, we ignore key registration a/b a/c b/a b/c c/b c/a
  20. Declarations — Key Idea Assume we have a series of

    subscribers Let’s see how the declarations may be propagated in the Zenoh network To keep the intuition, we ignore key registration a/b a/c b/a b/c c/b c/a c/a c/b a/b a/c b/a b/c
  21. Declarations — Key Idea Notice how Zenoh may generalize to

    reduce the declarations to be distributed over the network a/b a/c b/a b/c c/b c/a c/* c/* b/* b/* a/* a/*
  22. Declarations — Key Idea Notice how Zenoh may generalize to

    reduce the declarations to be distributed over the network a/b a/c b/a b/c c/b c/a b/* b/* c/* c/* a/* b/* a/* a/* c/* a/* b/* c/*
  23. Controlling Declaration Flow Zenoh was designed to minimize the declarations

    that fl ow over the network But in some cases there are devices so constrained that should not received any declarations This can be controlled with Interests a/b a/c b/a b/c c/b c/a b/* b/* c/* c/* a/* b/* a/* a/* c/* a/* b/* c/*
  24. Controlling Aggregation You can control aggregation by con fi guration

    Otherwise it will be Zenoh that will aggregate automatically aggregation: { subscribers: [ // key_expression ], queryable: [ // key_expression ], },
  25. Interests Zenoh provides a speci fi c protocol message to

    propagate interest and allo to control wether declarations are received or not By default interest are automatically asserted when declaring Publisher and Querier On the other hand, when using put and get, not interest is expressed
  26. Zenoh v1.x using put() & get() Router Peer Peer Router

    SUB B/* Peer SUB A/* Peer SUB C/* Peer PUB A/1 PUB W/1 Data fi ltering put() Data Subscribtions Data ← Sub A/* ← Sub B/* ← Sub C/*
  27. Zenoh v1.x using declare_publisher() & declare_querier() Router Peer Peer Router

    SUB B/* Peer SUB A/* Peer SUB C/* Peer PUB A/1 PUB W/1 Data fi ltering publisher.put() Data Subscribtions Subscription fi ltering declare_publisher() Subscribtions Interest Interest A/1 → ← Sub A/* ← Sub A/* ← Sub B/* ← Sub C/* Interest W/1 →
  28. Subscribing to Subscriptions - Dominic Cobb Interest Message 7 6

    5 4 3 2 1 0 +-+-+-+-+-+-+-+-+ |Z|Mod|INTEREST | +-+-+-+---------+ ~ id:z32 ~ +---------------+ |A|M|N|R|T|Q|S|K| if Mod!=Final +---------------+ ~ key_scope:z16 ~ if Mod!=Final && R==1 +---------------+ ~ key_suffix ~ if Mod!=Final && R==1 +---------------+ && N==1 -- <u8;z16> ~ [int_exts] ~ if Z==1 +---------------+ - Mode 0b00: Final - Mode 0b01: Current - Mode 0b10: Future - Mode 0b11: CurrentFuture - if K==1 interest for key expressions - if S==1 interest for subscribers - if Q==1 interest for queryables - if T==1 interest for liveliness tokens - if R==1 key expression, else all key expressions - if N==1 key expr has name/suffix - if M==1 sender mapping, else receiver mapping - if A==1 aggregated replies
  29. Interest Behavior A B | INTEREST | |------------------>| -- Mode:

    CurrentFuture | | Target: Subscribers | | | DECL SUBSCRIBER | |<------------------| | DECL SUBSCRIBER | |<------------------| | DECL SUBSCRIBER | |<------------------| | | | DECL FINAL | |<------------------| -- interest_id field set | | | DECL SUBSCRIBER | |<------------------| | UNDECL SUBSCRIBER | |<------------------| | | | ... | | | | INTEREST FINAL | |------------------>| -- Mode: Final | | Stops subscriber decls/undecls | |
  30. Routing Algorithm Zenoh supports two routing algorithms, link-state and peer-to-

    peer Link State can be used to route over arbitrary connected graphs Peer-to-Peer can only be used if every node in the graph is directly connected to every other node, in other term the graph is a clique Clique Connected Graph
  31. The graph is maintained up to date by sharing link-state

    messages when there is a topological change Every node computes the shortest path to every other node in the graph — this computation is done in such a way that all nodes compute the same path even in the presence of multiple (equivalent) paths The shortest path is used to route data Link State
  32. Peer to Peer Routing The routing problem is trivial here

    since every node has a direct link with every other node
  33. Composing Routing Algorithms Di ff erent routing algorithmes can be

    used for peers and for routers Additionally peers and routers create di ff erent routing domains thus increasing the scalability of the overall system Link state peer2peer peer2peer
  34. Con fi guring Routing By default routers are con fi

    gured to user link-state while peers to use peer-to-peer routing This default can be changed, if necessary through Zenoh custom con fi guration routing: { router: { mode: "linkstate", peers_failover_brokering: true, }, peer: { mode: "peer_to_peer", } }
  35. Retrieving the Routing Graph The graph currently used by a

    Zenoh node to route can be retrieved by simply querying the key @/{zid}/ router/linkstate/routers This will return the graph in dot format $ zenoh -e '["tcp/localhost:9001"]' graph \ -r 34f797e35493b213cf629378cbf75cc9 graph { 0 [ label = "34f797e35493b213cf629378cbf75cc9" ] 1 [ label = "583d4db6462765ec8ced600c98defb85" ] 2 [ label = "ca78bafc5425e05420229ab552f7de5a" ] 3 [ label = "690fd74942bab8e8d68bddb6f9173ac" ] 4 [ label = "38a7f63005e4135416ba1b76ca4e1f68" ] 1 -- 0 [ label = "100.76891604433045" ] 3 -- 0 [ label = "100.73397051792917" ] 2 -- 0 [ label = "100.17870163293058" ] 4 -- 0 [ label = "100.10234996539128" ] 2 -- 3 [ label = "100.93456648917277" ] 3 -- 4 [ label = "100.39134683050013" ] 4 -- 1 [ label = "100.19494506884247" ] }
  36. Key Highlights Zenoh is one of a kind protocol —

    it uni fi es data in motion, data at rest and computations It is the only protocol able to run from the microcontroller up to the datacenter It has not topological constraints It is extremely easy to use!