zyre: group messaging over a local network with no server

The characteristic list is the design

The overview states the goals as a list of characteristics, and the list reads like a set of requirements for a small local network.

Zyre needs no administration or configuration. Peers may join and leave the network at any time. Peers talk to each other without any central brokers or servers, and they can talk directly to each other. Peers can join groups and then talk to groups. It is reliable and loses no messages even when the network is heavily loaded. It is fast and has low latency, requiring no consensus protocols. It is designed for WiFi networks and also works well on Ethernet. And the time for a new peer to join a network is about one second.

Four of those are worth unpacking.

No central broker means there is nothing to run and nothing to scale, and it also means there is no queue and no replay, so a message sent while a peer is away is gone. That is a fair trade for a local network and a bad one for anything that needs delivery guarantees across restarts.

Peers joining and leaving at any time is the hard part of group messaging without a coordinator, and the one second figure is the cost of it. No consensus protocols means the peers do not agree on a membership list, they just gossip, which is why the library can claim both no administration and fast joining.

The use cases follow directly: local service discovery, clustering a set of services on the same Ethernet network, controlling a network of smart devices, and multi-user mobile applications such as smart classrooms. Note that all four are local, which is the boundary of the design.

The discovery mechanism and the reliability pattern

The technical details section is four bullets, and two of them are the interesting ones.

The first is that Zyre uses the ZRE protocol, a ZeroMQ specification, for discovery and heartbeating. The second is that it uses the reliable dealer and router pattern for interconnection, assuring that messages are not lost unless a peer application terminates. That qualifier is doing careful work. A peer that crashes loses what was in flight to it, but a peer that is still running and momentarily unreachable does not.

The third bullet says it is optimised for WiFi, using UDP broadcasts for discovery and heartbeating. The fourth says it offers an alternative discovery mechanism, gossip, for Ethernet networks.

That last bullet is the one to check against your network, because it is a genuine design fork rather than an optimisation. Broadcast discovery works well on a wireless network where a packet reaches everyone, and it does not work at all across a switched network without broadcast support, so the gossip mechanism exists for the wired case.

The dealer and router choice also explains the architecture. A router knows the topology and routes messages, and a dealer is a client that talks to a router, and the pair gives per-peer delivery guarantees without a central broker owning the state. The routers are the peers themselves, which is how the group membership survives peers leaving.

So the design is coherent: gossip or broadcast for finding peers, dealers and routers for reliable delivery between them, and no shared state anywhere that could become a single point of failure.

Building it on Linux and macOS

The build instructions are long, and that is mostly because the dependency stack has to be built by hand.

The package list is the first part, and it is comprehensive: git, the compiler and related tools, the GNU autoconf makefile generators, and CMake as an alternative, plus utility libraries, and a memory checker.

    sudo apt-get update
    sudo apt-get install -y \
    git build-essential libtool \
    pkg-config autotools-dev autoconf automake cmake \
    uuid-dev libpcre3-dev valgrind

Then come the four libraries, each cloned and built in turn. The first is a cryptography library, and the comment in the instructions is worth reading, because there is a lighter alternative for development.

    git clone --depth 1 -b stable https://github.com/jedisct1/libsodium.git

The second is the messaging library the project is built on, the third is the higher level binding layer above it, and the fourth is Zyre itself. Each follows the same four steps, generate the build files, configure, run the test suite, and install.

Two details are practical advice rather than procedure. The configuration step for the messaging library is told not to specify the optional cryptography library if you prefer to use the internal tweetnacl implementation, and the documentation marks that as recommended for development. And the library configuration is told to use the external one, which tells you the two paths serve different purposes.

The testing instructions are short and good. Run the self test binary, and then run the ping command from two or more machines to see discovery working.

    zyre/src/.libs/zpinger

The Windows build, and the language bindings

The Windows instructions are shorter, because the build system is a set of scripts rather than the autotools.

You need Visual Studio for C and C++, and the free community edition works well. Then git, and the build itself clones the same four repositories and runs a configure batch file followed by a build script, in a directory layout under the Visual Studio builds folder.

The self test and the ping tool are then run from the built output directories, with separate debug and release variants, and the instructions show how to locate them and pick one.

The bindings are the other thing in the tree worth noting. There is a Python binding, and its packaging script is minimal in a way that dates it, using the older packaging module with a fixed version and a package directory pointing at the Python bindings folder. There is also a Java binding, the examples directory includes a minimal example, a chat example, and a Java native interface example, and there is a C sharp style project definition file at the root alongside the other build descriptions.

So the library is usable from several languages, and the examples for each are small enough to read in a minute, which is the right way to learn a discovery protocol.

The repository also carries the infrastructure of a project that has been packaged for many distributions: an Open Build Service draft and stable entry, a Docker image, a Vagrantfile, a Jenkinsfile, AppVeyor and Travis configurations, and a set of CMake find modules for the dependencies.

Licence, contribution process and the state of the project

The ownership and licence section is short and points at a written process, which is the interesting part.

The project uses the MPL version 2 licence, the contributors are listed in a file in the repository, and contributions follow a named collective code construction contract process, with the code style governed by a separate written guide for scalable C style.

Those two documents are the same ones used across the ZeroMQ family, and adopting them is a deliberate choice. A project that wants contributions from many people across many companies needs a process that is written down, and the point of a construction contract process is that the rules for what a maintainer may require of a patch are decided in advance rather than argued about per patch.

The issue tracker is on the repository itself, which is a small thing that has become less small, because a project that is maintained through a mailing list and a tracker is easier to contribute to than one that is not.

On the state of the project, the release history is the thing to note. There is a version 0.0.4 from 2016, a version 2.0.0 from 2017, and a version 2.0.1 from January 2021. The last push was on 2026-08-19 with the repository not archived, so the code is being touched, but the packaged releases are five years old, which for a C library with a stable API is not necessarily a problem and does mean you should check the change log and the current state of the branch before relying on a tagged release.

The build and test tooling in the tree also shows a project that has been through a few eras. There is a Travis configuration for the older Linux and macOS builds, an AppVeyor configuration for Windows, a Jenkinsfile, and a set of scripts for continuous integration and for deploying to a package repository and to the Open Build Service. The mixture is what a decade of open source infrastructure looks like.

Editorial conclusion

zyre suits anyone building a set of applications that need to find each other and talk on the same network, whether that is a service mesh on an office Ethernet, a classroom of phones, or a set of sensors, because the discovery and the group membership are handled for you and there is no server to run. It is a poor fit across a wide area network, since the design assumes peers are close enough for broadcast discovery or for gossip to work, and a poor fit if you need durable message storage, since there is no broker and therefore no queue. Before you adopt it, read the discovery detail for your network type, because the broadcast and gossip mechanisms suit different topologies, and budget for building the dependency stack by hand, since the documentation is a sequence of clone and build steps rather than a package install.

Frequently asked questions

Official sources

1. Issues
2. License: MPL-2.0
3. README
4. Releases
5. zeromq/zyre on GitHub