[zeromq-dev] [otish] "Why ZeroMQ"

Pieter Hintjens ph at imatix.com
Tue Jul 27 11:10:43 CEST 2010

On Tue, Jul 27, 2010 at 10:57 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Note that CLIENT and COLLECTOR are redundant as CLIENT is just a worker
> that happens not to receive any messages and COLLECTOR is just a worker
> that happens not to send any messages.

The redundancy is what makes it comprehensible.  If you look at the
butterfly pattern you see that there are three roles: the node that
originates the workloads, the nodes that accept the work, and the node
that collects the results.

If you insist on reducing this to its minimum, you also strip out the
role of the nodes IMO, and come to the rather meaningless "single
socket that does it all but for technical reasons I need two sockets
so let me invent two random names".

Which does not map to the actual use case, which causes confusion.
There is no fault in using redundancy if it makes things more

> Which leaves us with a nice model with a single socket type...

No, that leaves you with nothing to hang your use case on.

Sink and source are better than the current upstream/downstream but
still do not reflect the actual role that the node is playing.

To choose good names you must approach this from the point of view of
the person using the pattern and ask, what does the user _expect_ that
a socket type would be called.

This is why you should document APIs before implementing them,
otherwise you push technical concerns like "I need two socket types to
distinguish between the binding and connecting peers" into user space,
which is totally the wrong way to design an API.

BTW the nomenclature proposed (which I don't defend, but just hold as
an example of a properly unsurprising design) won't work unless the
pattern name is included in the socket type.  "Client" is also perfect
for the request/response pattern, better than "request" (which is the
message type, not the role of the node).

Sorry to rant, but the inconsistency in these names just hurts and
will keep hurting until it is properly resolved.


More information about the zeromq-dev mailing list