[zeromq-dev] Explicit patterns

Pieter Hintjens ph at imatix.com
Tue May 25 00:04:03 CEST 2010

Hi all,

I'm writing a guide for 0MQ beginners and I've hit two problems in
understanding and explaining 0MQ, which I think are faced by many
people before they really know 0MQ well. The first problem is that 0MQ
patterns, which are really important building blocks, are not 1st
class entities.  A pattern is a set of socket types and devices but
those names don't mention patterns at all.  There is no hint of what
combinations of socket and device are legal.  We have to learn it all
by heart.

Second problem is that the socket types are irregular.  For
request-reply they indicate the type of message a node sends.  For
pub-sub they are the role of the node.  For paralyzed processing they
indicate the flow of data.  For pair they indicate the nature of the

So it seems inevitable that people will misuse socket types and
patterns until they learn by error.  We lack a consistent model of
what a pattern is and how the names of things are derived.

Here's a proposal that will fix this, we think.  We being Mato and
myself.  It's going to hurt but it's arguably better now than later.
We propose these consistent rules:

* All socket types and devices names contain the pattern identifier.
We suggest RR, PS, BF, and EP for request-response, pub-sub,
butterfly, and exclusive pair respectively.
* Socket and device types are named ZMQ_XX_YYYY where XX is the
pattern identifier and YYYY is the socket or device type.
* Socket types always reflect the role of the node, period.

This gives us (as example, the details may change):

* ZMQ_RR_CLIENT, ZMQ_RR_SERVER for sockets, ZMQ_RR_QUEUE for device.
ZMQ_BF_STREAMER for device.
* ZMQ_EP_PEER for sockets.

Incidental change proposals are to rename parallelized process as
"butterfly" and pair as "exclusive pair" to give these patterns more
friendly names.

Comments, thoughts?


(Also posted at http://www.zeromq.org/draft:explicit-patterns)

More information about the zeromq-dev mailing list