CEO / CTO ZettaScale Technology Angelo Corsaro, PhD Advanced Zenoh Tutorial Episode 4 

Awesome Zenoh List of awesome open source projects use and extend Zenoh 

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 

Get It. Build It. Run It $ git clone [email protected]:kydos/zsak.git $ cd zsak $ cargo build —release $ ./target/release/zenoh -h 

Discovery 

Scouting 

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 

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 

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) 

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 

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 

Default Behavior By default Zenoh routers don’t do multicast scouting - Zi Zj Zk Za Zb Zc Router 

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, } } 

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 

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 

Gossip Scouting Pi R The peer Pi is started and opens a session with R 

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 

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 

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" } }, }, }, 

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"] } 

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 

Discovery 

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 

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 

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) 

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 

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 

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/* 

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/* 

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/* 

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 ], }, 

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 

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/* 

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 → 

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 -- ~ [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 

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 | | 

Routing 

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 

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 

Peer to Peer Routing The routing problem is trivial here since every node has a direct link with every other node 

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 

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", } } 

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" ] } 

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! 

Patience, persistence and perspiration make an unbeatable combination for success. Thank You