[zeromq-dev] zmq-socket name aliases (was: Re: Why ZeroMQ?)

Brian Granger ellisonbg at gmail.com
Tue Jul 27 19:00:15 CEST 2010

I am really not fond of renaming the sockets other than UPSTREAM/DOWNSTREAM.
 Every alternate naming scheme I have seen has just as many (or more!)
problems as the existing one and uses longer names that are a pain to type.
 In interactive languages like Python, you end up typing these names a lot,
so length matters.  Tab completion helps, but not much when there are
prefixes like SOCK and REQREP.

Here is how I look at names like this:

Imagine that understanding the various socket types is like a key/value
store in our heads.  In this picture, the KEY is the name we use to refer to
the socket types and the VALUE is our full understanding of the socket types
that includes all of the subtle details.  For example:

REQ (key) = sends requests to REP socket, uses SRSRSR pattern, Load balanced
and last peer strategies. (value)

Most importantly, KEY != VALUE.  That is, the name we use to refer to each
socket does not have to include all the information about the socket, it
merely has to be a unique identifier that is not confusing.  The longer
naming schemes feel like they are trying to put the VALUE into the KEY,
i.e., all of the details of the socket into the name of the socket.

When a name represents a complex set of details, certain things are

* The name should be short, unique and have something to do with the
underlying details.  The current names do that, with the exception of
UPSTREAM/DOWNSTREAM which are ambiguous.
* The name should not change.  It takes a lot of work to learn all of the
details of the 0MQ sockets.  For example, I spent a long time
learning/remembering all of the things that XREP/XREQ socket do.  Having
longer names would not have helped in any way.  If these names change,
everyone who has learned the details of the various socket types will have
to relearn these associations, increasing the mental load required to use

A few specific comments are below.

On Tue, Jul 27, 2010 at 8:55 AM, Oliver Smith <oliver at kfs.org> wrote:

>  Pieter's list:
> http://www.zeromq.org/draft:socket-type-names
Any usage of the words client/server/service is horribly confusing in the
0MQ context.  This is because for many people server/client refers to which
process binds and which process connects.  Because the bind/connect in 0MQ
is independent of the REQ/REP direction, this is just confusing.  If you
gave all of us a picture of various 0MQ based applications and asked the
question, "which is the server and which is the client" I expect you would
get a perfectly random distribution of answers.

Same issue of client/server/service.

This seems quite redundant.  I don't understand why PUB/SUB is not clear

>    -
> I do think these sockets should be renamed, but these alternatives seem
very verbose.  I like some of the other, shorter ones that have been given.

Again, I don't see how the long name communicates anything more than the
current one.

> My $0.01 (I'm too cheap to go the whole $0.02 just yet ;)
> Primarily: using stdin/stdout may cause naming conflicts and confusion --
> they are only borrowing from the concept of stdin/stdout, they are in no way
> related. Plus we don't want someone to misunderstand them as the default
> sockets for zmq.
> ZMQ_SOCK_REQREP_GENERATOR (aka ZMQ_REQ, the requester)  =>
> zmq.sock.reqrep.generator
> ZMQ_SOCK_REQREP_BROKER (alias for ZMQ_REP, the responder) =>
> zmq.sock.reqrep.broker
> ZMQ_SOCK_REQREP_BROKER_ASYNC (aka ZMQ_XREP)        => problem

I think "broker" is not an accurate representation of a socket and has too
many connotations in messaging (that of a central process that manages

> ZMQ_SOCK_BROADCAST_PUBLISHER (aka ZMQ_PUB) => zmq.sock.broadcast.publisher
> zmq.sock.broadcast.subscriber
> ZMQ_SOCK_PIPELINE_OUT (aka ZMQ_POUT) => zmq.sock.pipeline.out
> ZMQ_SOCK_PIPELINE_IN (aka ZMQ_PIN) => zmq.sock.pipeline.in
> ZMQ_SOCK_EXCLUSIVE_PEER (aka ZMQ_PAIR) => zmq.sock.exclusive.peer
> - Oliver
> _______________________________________________
> 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/20100727/0e85d68a/attachment.htm>

More information about the zeromq-dev mailing list