ZeroMQ

The Clustered Hashmap Protocol

While the Model Six server is pretty much a mashup of the previous model plus the Binary Star pattern, the client is quite a lot more complex. But before we get to that, let’s look at the final protocol. I’ve written this up as a specification on the ZeroMQ RFC website as the Clustered Hashmap Protocol (CHP).

Roughly, there are two ways to design a complex protocol such as this one. One way is to separate each flow into its own set of sockets. This is the approach we used here. The advantage is that each flow is simple and clean. The disadvantage is that managing multiple socket flows at once can be quite complex. Using a reactor makes it simpler, but still, it makes a lot of moving pieces that have to fit together correctly.

The second way to make such a protocol is to use a single socket pair for everything. In this case I’d have used ROUTER for the server and DEALER for the clients, and then done everything over that connection. It makes for a more complex protocol, but at least the complexity is all in one place. In Chapter 7 we’ll look at an example of a protocol done over a ROUTER-DEALER combination.

Let’s read through the CHP specification now. This text is taken directly from the RFC. Note that “SHOULD” and “MUST” are keywords that we use in protocol specifications to indicate requirement levels.

Goals

CHP is meant to provide a basis for reliable pub-sub across a cluster of clients connected over a ØMQ network. It defines a “hashmap” abstraction ...