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

Nicholas Piël nicholas at nichol.as
Tue Jul 27 11:45:56 CEST 2010


On Jul 27, 2010, at 10:40 AM, Pieter Hintjens wrote:

> On Tue, Jul 27, 2010 at 3:30 AM, Matt Weinstein
> <matt_weinstein at yahoo.com> wrote:
> 
>> I've been using ZMQ_STREAM_SOURCE and ZMQ_STREAM_SINK.
>> There's still that "from which perspective?" problem.
> 
> It would be more consistent IMO to always name sockets after the role
> that the node plays.  

I am not really sure about this, wouldn't it be best to name the socket after the role the socket plays? 

For example, in a butterfly example the worker nodes have two types of socket they collect from the upstream and push their info downstream. This clearly shows the unidirectional flow of messages. 

I don't think SINK or SOURCE is a better naming as well. In a pipeline pattern a worker node is never the real source or the sink and it becomes more difficult to understand the grand scheme. This means for example that in a worker node you will have to receive on the SINK socket and send to the SOURCE socket. Sounds counter-intuitive to me.

> Now, request/response are named after the type
> of message, publish/subscriber after the role of the node, and
> upstream/downstream are perversely named after the role of the
> /receiving/ node.

Well, I think that the current naming is closely tied to the message pattern and to be honest I think that is the only sensible way to do it. 

Ie, req/rep says something about the flow of message through the socket not directly the message it self (as it can be both a response or a request). The same goes for pub/sub and up/down. 


> This is not about requiring paradigm shifts or better documentation,
> it's about using consistent names that provide some kind of model the
> poor developer can depend on.
> 
> The names Mato and I proposed for the pipeline pattern were:
> 
> ZMQ_BF_CLIENT, ZMQ_WORKER, ZMQ_COLLECTOR

I really think these would cause LOTS of troubles. Even in this specifically example you mostly have a server that produces items to be named client. 

Or take a look at the req/rep example, it isn't that difficult to imagine a protocol where the server initiates a request to clients. Where the node naming would turn it upside down.






More information about the zeromq-dev mailing list