[zeromq-dev] [otish] "Why ZeroMQ"
ellisonbg at gmail.com
Tue Jul 27 16:58:58 CEST 2010
On Tue, Jul 27, 2010 at 2:36 AM, Martin Lucina <mato at kotelna.sk> wrote:
> ph at imatix.com said:
> > On Tue, Jul 27, 2010 at 10:57 AM, Martin Sustrik <sustrik at 250bpm.com>
> > > 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.
> Please note that this only applies if you're using UPSTREAM/DOWNSTREAM
> sockets to implement the "butterfly" design. There are other options where
> the roles of each node are nowhere near as clear-cut as you make them out
> to be.
> The same applies for request/reply, at least when using XREQ/XREP. It is
> not required that "the node using XREQ" is "the client" or "the node using
> XREP" is "the service", see for example Brian Granger's message as of a few
> days ago about "clever uses of XREQ/XREP", all of which are legitimate.
> In retrospect, my view is that while "naming the sockets after the nodes
> role in the topology" seems like a good idea at first sight, in practice it
> would cause more harm than good.
> > 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".
> Well, the reason we ditched the idea of a WORKER socket is that it does
> seem to be technically impossible to implement in a way that fits with the
> existing APIs. Perhaps you have a consistent proposal how to implement it?
> > 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.
> You are not taking into account the fact that the 0MQ API was designed
> explicitly to look like POSIX sockets, with the long term view of
> integration into kernel space, which is not the same as desiging an API
> from scratch.
> > 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).
> See above.
> > Sorry to rant, but the inconsistency in these names just hurts and
> > will keep hurting until it is properly resolved.
> Maybe just get over it, use the product, and be happy? :-)
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev