Key concepts
Deployment units
zenoh provides 3 kinds of deployment units: peers, clients and routers.
peer application
A user application using a zenoh API and able to:



client application
A user application using a zenoh API and that connects to a single zenoh router (or a single peer) to communicate with the rest of the system.

zenoh router
A software process able to route the zenoh protocol between clients and peers in any given topology.

The router executable file is named
zenohd
and is available in zenoh releases, as a Docker image or building it by yourself.User APIs
zenoh provides 2 levels of API:
zenoh-net
A network oriented API providing the key primitives to allow pub/sub (push) communications as well as query/reply (pull) communications. The zenoh-net layer only cares about data transportation and doesn’t care about data content nor storing data.
zenoh
A higher level API providing the same abstractions as the zenoh-net API in a simpler and more data-centric oriented manner as well as providing all the building blocks to create a distributed storage. The zenoh layer is aware of the data content and can apply content-based filtering and transcoding.
zenoh-net primitives
- write : push live data to the matching subscribers.
- subscribe : subscriber to live data.
- query : query data from the matching queryables.
- queryable : an entity able to reply to queries.
zenoh primitives
- put : push live data to the matching subscribers and storages. (equivalent of zenoh-net write)
- subscribe : subscriber to live data. (equivalent of zenoh-net subscribe)
- get : get data from the matching storages and evals. (equivalent of zenoh-net query)
- storage : the combination of a zenoh-net subscriber to listen for live data to store and a zenoh-net queryable to reply to matching get requests.
- eval : an entity able to reply to get requests. Typically used to provide data on demand or build a RPC system. (equivalent of zenoh-net queryable)