ZeroMQ

Working with Subtrees

As we grow the number of clients, the size of our shared store will also grow. Eventually, it stops being reasonable to send everything to every client. This is the classic story with publish-subscribe: when you have a very small number of clients, you can send every message to all clients, but as you grow the architecture this becomes inefficient. Clients specialize in different areas.

So, even when working with a shared store, some clients will want to work only with a part of that store, which we call a subtree. The client has to request the subtree when it makes a state request, and it must specify the same subtree when it subscribes to updates.

There are a couple of common syntaxes for trees. One is the path hierarchy, and another is the topic tree. These look like this:

• Path hierarchy: /some/list/of/paths

• Topic tree: some.list.of.topics

We’ll use the path hierarchy and extend our client and server so that a client can work with a single subtree. Once you see how to work with a single subtree, you’ll be able to extend this yourself to handle multiple subtrees if your use case demands it.

Example 5-34 shows the server implementing subtrees, a small variation on Model Three.

Example 5-34. Clone server, Model Four (clonesrv4.c)

//
//  Clone server — Model Four
//

//  Lets us build this source without creating a library
#include "kvsimple.c"

//  Routing information for a key-value snapshot
typedef struct {
    void *socket;           //  ROUTER socket to send to
    zframe_t *identity ...