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.