I've been using ZMQ_STREAM_SOURCE and ZMQ_STREAM_SINK. There's still that "from which perspective?" problem.
How about ZMQ_IWANTBYTES and ZMQ_IGOTBYTES :-) 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 > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
