zenoh icon indicating copy to clipboard operation
zenoh copied to clipboard

zenoh unifies data in motion, data in-use, data at rest and computations. It carefully blends traditional pub/sub with geo-distributed storages, queries and computations, while retaining a level of ti...

CI Documentation Status Discussion Discord License License

Eclipse zenoh

The Eclipse zenoh: Zero Overhead Pub/sub, Store/Query and Compute.

Eclipse zenoh (pronounce /zeno/) unifies data in motion, data in-use, data at rest and computations. It carefully blends traditional pub/sub with geo-distributed storages, queries and computations, while retaining a level of time and space efficiency that is well beyond any of the mainstream stacks.

Check the website zenoh.io and the roadmap for more detailed information.


How to install and test it

See our "Getting started" tour starting with the zenoh key concepts.


How to build it

Install Cargo and Rust. Zenoh can be succesfully compiled with Rust stable (>= 1.5.1), so no special configuration is required from your side.
To build zenoh, just type the following command after having followed the previous instructions:

$ cargo build --release --all-targets

The zenoh router is built as target/release/zenohd. All the examples are built into the target/release/examples directory. They can all work in peer-to-peer, or interconnected via the zenoh router.


Previous 0.5 API:

The following documentation pertains to the v0.6 API, which comes many changes to the behaviour and configuration of Zenoh.

To access the v0.5 version of the code and matching README, please go to the 0.5.0-beta.9 tagged version.


Quick tests of your build:

Peer-to-peer tests:

  • pub/sub

    • run: ./target/release/examples/z_sub
    • in another shell run: ./target/release/examples/z_put
    • the subscriber should receive the publication.
  • get/eval

    • run: ./target/release/examples/z_eval
    • in another shell run: ./target/release/examples/z_get
    • the eval should display the log in its listener, and the get should receive the eval result.

Routed tests:

  • put/store/get

    • run the zenoh router with a memory storage:
      ./target/release/zenohd --cfg='plugins/storage_manager/storages/demo:{key_expr:"/demo/example/**",volume:"memory"}'
    • in another shell run: ./target/release/examples/z_put
    • then run ./target/release/examples/z_get
    • the get should receive the stored publication.
  • REST API using curl tool

    • run the zenoh router with a memory storage:
      ./target/release/zenohd --cfg='plugins/storage_manager/storages/demo:{key_expr:"/demo/example/**",volume:"memory"}'
    • in another shell, do a publication via the REST API:
      curl -X PUT -d 'Hello World!' http://localhost:8000/demo/example/test
    • get it back via the REST API:
      curl http://localhost:8000/demo/example/test
  • router admin space via the REST API

    • run the zenoh router with a memory storage:
      ./target/release/zenohd --cfg='plugins/storage_manager/storages/demo:{key_expr:"/demo/example/**",volume:"memory"}'
    • in another shell, get info of the zenoh router via the zenoh admin space:
      curl http://localhost:8000/@/router/local
    • get the volumes of the router (only memory by default):
      curl 'http://localhost:8000/@/router/local/**/volumes/*'
    • get the storages of the local router (the memory storage configured at startup on '/demo/example/**' should be present):
      curl 'http://localhost:8000/@/router/local/**/storages/*'
    • add another memory storage on /demo/mystore/**:
      curl -X PUT -H 'content-type:application/json' -d '{"key_expr":"/demo/mystore/**","volume":"memory"}' http://localhost:8000/@/router/local/config/plugins/storage_manager/storages/mystore
    • check it has been created:
      curl 'http://localhost:8000/@/router/local/**/storages/*'

See other examples of zenoh usage in zenoh/examples/zenoh


zenoh router command line arguments

zenohd accepts the following arguments:

  • -c, --config <FILE>: a JSON5 configuration file. EXAMPLE_CONFIG.json5 shows the schema of this file. All properties of this configuration are optional, so you may not need such a large configuration for your use-case.

  • --cfg <KEY>:<VALUE> : allows you to change specific parts of the configuration right after it has been constructed. VALUE must be a valid JSON5 value, and key must be a path through the configuration file, where each element is separated by a /. When inserting in parts of the config that are arrays, you may use indexes, or may use + to indicate that you want to append your value to the array. --cfg passed values will always override any previously existing value for their key in the configuration.

  • -l, --listen <ENDPOINT>...: An endpoint on which this router will listen for incoming sessions. Repeat this option to open several listeners. By default, tcp/0.0.0.0:7447 is used. The following endpoints are currently supported:

    • TCP: tcp/<host_name_or_IPv4_or_IPv6>:<port>
    • UDP: udp/<host_name_or_IPv4_or_IPv6>:<port>
    • TCP+TLS: tls/<host_name>:<port>
    • QUIC: quic/<host_name>:<port>
  • -e, --connect <ENDPOINT>...: An endpoint this router will try to connect to. Repeat this option to connect to several peers or routers.

  • --no-multicast-scouting: By default zenohd replies to multicast scouting messages for being discovered by peers and clients. This option disables this feature.

  • -i, --id <hex_string>: The identifier (as an hexadecimal string - e.g.: 0A0B23...) that zenohd must use. WARNING: this identifier must be unique in the system! If not set, a random UUIDv4 will be used.

  • --no-timestamp: By default zenohd adds a HLC-generated Timestamp to each routed Data if there isn't already one. This option disables this feature.

  • -P, --plugin [<PLUGIN_NAME> | <PLUGIN_NAME>:<LIBRARY_PATH>]...: A plugin that must be loaded. Accepted values:

    • a plugin name; zenohd will search for a library named libzplugin_<name>.so on Unix, libzplugin_<PLUGIN_NAME>.dylib on MacOS or zplugin_<PLUGIN_NAME>.dll on Windows.
    • "<PLUGIN_NAME>:<LIBRARY_PATH>"; the plugin will be loaded from library file at <LIBRARY_PATH>.

    Repeat this option to load several plugins.

  • --plugin-search-dir <DIRECTORY>...: A directory where to search for plugins libraries to load. Repeat this option to specify several search directories'. By default, the plugins libraries will be searched in: '/usr/local/lib:/usr/lib:~/.zenoh/lib:.'

  • --rest-http-port <rest-http-port>: Configures the REST plugin's HTTP port. Accepted values:

    • a port number
    • a string with format <local_ip>:<port_number> (to bind the HTTP server to a specific interface)
    • "None" to desactivate the REST plugin

    If not specified, the REST plugin will be active on any interface (0.0.0.0) and port 8000.


Plugins

By default the zenoh router is delivered or built with 2 plugins. These may be configured through a configuration file, or through individual changes to the configuration via the --cfg CLI option or via zenoh puts on individual parts of the configuration.

WARNING: since v0.6, zenohd no longer loads every available plugin at startup. Instead, only configured plugins are loaded (after processing --cfg and --plugin options). Currently, plugins may only be loaded at startup.

Note that the REST plugin is added to the configuration by the default value of the --rest-http-port CLI argument.

REST plugin (exposing a REST API): This plugin converts GET and PUT REST requests into Zenoh gets and puts respectively.

Storages plugin (managing backends and storages) This plugin allows you to easily define storages. These will store key-value pairs they subscribed to, and send the most recent ones when queried. Check out EXAMPLE_CONFIG.json5 for info on how to configure them.


Troubleshooting

In case of troubles, please first check on this page if the trouble and cause are already known.
Otherwise, you can ask a question on the zenoh Discord server, or create an issue.