On Wed, Jul 28, 2010 at 7:30 AM, Serge Aleynikov <[email protected]>wrote:
> 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.
>
>
I do agree with this at some level. 0MQ occupies a very odd position in the
network stack. In some ways it is very low-level (connectionless, raw bytes
wire protocol) and in other ways it is very high-level (load balancing, qos,
etc.). At the same time all other solutions I have used are high-level and
low-level in all the wrong place.
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, "ser...@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
> > [email protected] <mailto:[email protected]>
> > [email protected] <mailto:[email protected]>
> >
> >
> >
> > _______________________________________________
> > zeromq-dev mailing list
> > [email protected]
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
[email protected]
[email protected]
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
