[zeromq-dev] zmq-socket name aliases

[Pieter Hintjens]

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.

-Pieter