[zeromq-dev] zmq-socket name aliases

Matt Weinstein matt_weinstein at yahoo.com
Thu Jul 29 02:27:20 CEST 2010


On Jul 28, 2010, at 6:36 PM, Pieter Hintjens 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.
>
> 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.
>
> 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.
>

Classic separation of policy and implementation -- provide orthogonal  
capabilities to construct systems based on patterns derived from usage  
and use cases.

Sounds like set of formal GoF style Design Patterns would be sensible  
right about now, e.g. "The ØMQ Pattern Language : Design Patterns for  
High-Performance Networking" -- or some such.

(Excuse me, I've got to dust off the ol' Christopher Alexander tomes  
now... :-) )


> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Best,
Matt


More information about the zeromq-dev mailing list