[zeromq-dev] zmq-socket name aliases

[Serge Aleynikov]

Brian,

> Hope I don't seem too stubborn about this.  I do like the idea of
> renaming the UPSTREAM/DOWNSTREAM sockets and I hope the momentum for
> that doesn't get lost.

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.

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.

The 0MQ sockets have session, presentation and possibly some of the 
application layers intrinsically mixed together.  As a result they are 
not really "sockets" but endpoints (?), mailboxes (?), nodes (?), and 
communication channels combined.  While the API is modeled after BSD 
sockets, the implementation beefs them up with rich features of upper 
layers, and as a result the notion of a socket as communication channel 
is somewhat lost together with the ability to identify communicating 
entities.

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?

E.g., here's the pseudo-code of the separation I am talking about:

Server:
     ctx      = zmq_init(IoThreads)
     endpoint = zmq_create_endpoint(ctx, "Server at host", ZMQ_REQ)
     // All messages received on socket will be delivered
     // to the endpoint.  The messages would carry the
     // identify of the sender's endpoint
     socket   = zmq_socket(endpoint, options)
     zmq_bind(socket, "tcp://host:port")

     while (true) {
         zmq_recv(endpoint, msg, flags)
         printf("Msg from %s\n", msg->endpoint())
         ...
         // Get the socket to be used to send a reply
         sock = msg->socket()
         // If endpoint uses a different design pattern that
         // needs load balancing, the reply socket can be
         // obtained by calling a function at the endpoint-level
         // that will take the client endpoint's identity and the
         // options representing a balancing strategy:
         sock = zmq_get_socket(endpoint, msg->endpoint(), options)

         zmq_send(sock, reply)
     }

What's accomplished here is that endpoints have identities and sockets 
are used as communication channels, where the endpoint controls use of 
sockets and has a feature of figuring out which sockets to use to relay 
a message to its origin, whereas it itself controls the high-level 
balancing and other strategies.

I am augmenting the client pseudo-code, but hope the point is clear.

My 2c.

Serge

>
>      > Any usage of the words client/server/service is horribly
>     confusing in the
>      > 0MQ context.
>
>     I'm not going to defend the long names if people feel they clumsy and
>     pointless, but 'client' and 'server' are formally defined in
>     http://api.zeromq.org/zmq_socket.html and though I'm often pretty
>     confused about many things, these were always clear.
>
>
> I didn't know this, so I looked on this web page and found the following:
>
> "many-to-one (many clients, one server)"
>
> This definition implies that server = bind, client = connect.
>
> And also:
>
> "The request-reply pattern is used for sending requests from a client to
> one or more instances of a service"
>
> This implies that server = REP, client = REQ.
>
> Are not these two definitions contradictory?
>
>     Sure, you can
>     have networks where services connect to clients but then you _know_
>     you're doing weird stuff.
>
>
> Then I think 0MQ is weird :)
>
>     Actually, calling them 'client' and 'server' (for reqrep) IMO helps by
>     telling users 'you really should be binding the server socket and
>     connecting the client socket' (in 95% of cases).  Network
>     architectures aren't random.  Clients are generally a lot more dynamic
>     than services.
>
>
> I completely agree that most people will want to use the canonical
> directions, but I do think it is misleading to hide the fact that the
> choice of bind/connect is completely independent of the socket type.
>   When people ask me if a socket should bind or connect, I tell them
> that the decision to bind/connect is independent of the socket type and
> that if you want a socket to have multiple peers, it should bind, a
> single peer, it should connect.
>
>
>     -Pieter
>
>
>
>
> --
> Brian E. Granger, Ph.D.
> Assistant Professor of Physics
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu <mailto:bgranger at calpoly.edu>
> ellisonbg at gmail.com <mailto:ellisonbg at gmail.com>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev