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

Matt Weinstein matt_weinstein at yahoo.com
Tue Jul 27 03:30:37 CEST 2010


There's still that "from which perspective?" problem.


On Jul 26, 2010, at 6:35 PM, Oliver Smith wrote:

> On 7/26/2010 3:40 PM, Nicholas Piël wrote:
>> I personally think that the naming of upstream/downstream is  
>> perfect for this unidirectional pattern. I use the 'wild water' or  
>> 'waterfall' metaphor where you can send something downstream but it  
>> is impossible to send something upstream (unless your a Trout).
> I get that :) The problem is arises depending what level or end of the
> system you are looking at.
> For example - some people think of the connection pair in terms of
> recipient. In this case, the recipient is a ZMQ_UPSTREAM.
> For some people, it's a reversed perspective to what you have to take
> with REQ/REP, the local socket type is named based on your role. With
> DOWN/UP the local socket type is named on the destination.
> It makes sense at first, in both cases, the local socket name is  
> sensible;
>     msg->ZMQ_REQ ... "I am sending a request".
>     msg->ZMQ_DOWNSTREAM ... "I am sending data downstream"
> But on the remote end the down/up becomes ambiguous.
>     ZMQ_UPSTREAM->recv ... Wait ... I'm receiving this from upstream?
> Just to emphasize the point: There are some disciplines in which
> "upstream" is the place that you send things, because things flow
> downstream of their own accord. Salmon only ever worry about swimming
> upstream. You would then wonder why you were writing data "downstream"
> (since that's what the socket is named).
> ZMQ_SENDPLINE and ZMQ_RECVPLINE would work. PipeLINE pattern, sending
> endpoint, recving endpoint. (ZMQ_SENDPIPE people might go "but I want
> tcp not a pipe" ;))
> Although I think REQ/REP suffer far less from the language barrier  
> than
> UP/DOWN, you could avoid orientation issues (why am I not receiving  
> on a
> REQ socket?) by aliasing them
> ZMQ_SENDRECV and ZMQ_RECVSEND. The pattern again being clearly
> documented in the name. Down side: New users are going to mistake  
> these
> for PAIR, so
> ZMQ_SENDTORECV and ZMQ_RECVTOSEND. Not as pretty as REQ and REP... But
> disambiguation never hurt :) (Well, unless you are disambiguating to
> your best friend that it was /his/ sister you had a date with last
> night, but that is hardly a fair argument! :)
> ZMQ_PUB and ZMQ_SUB work fine because they are descriptive rather than
> directional.
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list