[zeromq-dev] zmq-socket name aliases
Brian Granger
ellisonbg at gmail.com
Thu Jul 29 18:46:57 CEST 2010
On Wed, Jul 28, 2010 at 3:36 PM, Pieter Hintjens <ph at imatix.com> wrote:
> On Wed, Jul 28, 2010 at 4:30 PM, Serge Aleynikov <serge at aleynikov.org>
> wrote:
>
> > You're certainly not the only one having trouble with the naming of
> > UPSTREAM/DOWNSTREAM sockets. Every time I think this notion is settled
> > in my head, if I stop thinking about it and come back to it in a few
> > days I have the same trouble in identifying the roles, which to me
> > clearly indicates of a poor naming choice.
>
> I think this is just because you need to think in terms of the
> topology to understand all the patterns except for pipeline, where you
> need to think in terms of that node alone.
>
> > However, maybe the problem is not just with names but with the fact that
> > the 0MQ project tries to be too ambitious in squeezing many concepts
> > into a single layer of the stack? There is a reason OSI is made up of 7
> > layers where each has its own role and API.
>
> That was IMO because there were 8 committees. One had to be in charge. :-)
>
> > I don't mean to criticize the design too much at this point as I am sure
> > there's a reason for 0MQ architecture being done the way it's
> > implemented, but this lack of role separation in design is likely what's
> > causing much of confusion. Perhaps if the design treated sockets as
> > identifiable endpoints more explicitly, and had another layer for
> > defining communication patterns with a separate API, there would be less
> > trouble with concepts?
>
> This is the discussion Martin and I have been having about what 0MQ/3
> might look like. There are use cases (such as authenticated data
> distribution, or indeed any custom pattern) where we want the whole
> 0MQ stack except routing. If 0MQ exposes the connections
> individually, then all patterns could be built on top of the core.
>
> Take this a step further and we could create an abstract socket type,
> e.g. 0MQ_RAW, which gave us full control over every aspect of the
> pattern in a runtime configurable manner. I.e. what's the exception
> strategy, what's the queuing strategy, is there an identity added
> yes/no, customized filtering, customized routing.
>
> All this could be layered on top of raw 0MQ sockets in such a way that
> the existing socket types become a pretty thin layer, easily extended
> with custom code.
>
>
Interesting, I have ben thinking about this lately as well. The reason I
started to think about this is that there are a core set of capabilities
that 0MQ sockets have like:
* HWM handling (discard or block)
* Outbound routing (multcast, load balance, identity based routing, etc.,
topics)
* Inbound routing (fair queing)
* Number of peers (1, many)
* Directional (R, W, RW)
* Sync/async, etc.
All of these things could be options to a lower level socket object. This
would allow the building of other socket types as well as the current types.
BUT, I am worried that this is too much flexibility and that 90$ of the
combinations don't make sense. So, to go this direction, I think we would
have to have a really strong reason to do so. What could people do, that
they actually need to do, that they can't now?
> However... while this may appeal to those of us who like to make
> things... it would IMO be a Bad Idea to expose this to normal 0MQ
> users except carefully wrapped up as the existing socket types.
> Abstraction is harder to understand than concreteness.
>
>
Yes, whatever happens in 0MQ3, I hope that the user/dev facing APIs can
remain the same or evolve gradually. 0MQ has gained a ton of momentum and
we and others are now building real apps with it. While I am all for
incremental evolution of the API to improve features and address
limitations, I think major API breakage or redesign would be a bad thing at
this point....such as happened to AMQP with the 1.0 spec...
> We learned this lesson with AMQP which does not give you patterns but
> instead building blocks that you must glue together to make patterns.
> The flexibility seems fantastic but in fact makes even the simplest
> work quite delicate. You can create 50-odd patterns with AMQP but
> only 4 or 5 make any sense at all.
>
> To conclude:
>
> * The confusion over the pipeline socket types can IMO be fixed with a
> rename that conforms to a topological view. ZMQ_SOURCE / ZMQ_SINK or
> ZMQ_FANOUT / ZMQ_FANIN seem to work topologically.
>
> * We continue to think about splitting 0MQ into a raw socket layer
> plus pattern layer. It may be possible to add raw sockets to 0MQ
> without major changes to existing socket types, and experiment with
> this for a while.
>
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
--
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...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100729/6d6edf51/attachment.htm>
More information about the zeromq-dev
mailing list