True Peer Connectivity (Harmony Pattern)

Since ØMQ is designed to make distributed messaging easy, people often ask how to interconnect a set of true peers (as compared to obvious clients and servers). It is a thorny question, and ØMQ doesn’t really provide a single clear answer.

TCP, which is the most commonly used transport in ØMQ, is not symmetric; one side must bind and one must connect, and though ØMQ tries to be neutral about this, it’s not. When you connect, you create an outgoing message pipe. When you bind, you do not. When there is no pipe, you cannot write messages (ØMQ will return EAGAIN).

Developers who study ØMQ and then try to create N-to-N connections between sets of equal peers often try a ROUTER-to-ROUTER flow. It’s obvious why: each peer needs to address a set of peers, which requires ROUTER. It usually ends with a plaintive email to the list.

Experience teaches us that ROUTER-to-ROUTER is particularly difficult to use successfully. At a minimum, one peer must bind and one must connect, meaning the architecture is not symmetrical. But also, you simply can’t tell when you are allowed to safely send a message to a peer. It’s a Catch-22: you can talk to a peer after it’s talked to you, but the peer can’t talk to you until you’ve talked to it. One side or the other will be losing messages and thus has to retry, which means the peers cannot be equal.

I’m going to explain the Harmony pattern, which solves this problem, and which we use in Zyre.

Get ZeroMQ now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.