FWIW, we are currently using a patched version of zproto message codec to support multi-hop messages by tracking routing info as an envelope of zero or more frames instead of as zero or one frames. I'm not afraid of change, but I'm still trying to work out how we are going to change our architecture to not use multi-hop request/reply multi-frame semantics.
One thing I thought I'd bring up here is zmq_proxy, which we are using extensively to funnel traffic from many client (DEALER) sockets on a single machine so that we can redirect them all to a different server (ROUTER) at will. This is part of why we support a variable number of hops between client and server. It's not clear to me whether zmq_proxy could work correctly or at all with CLIENT/SERVER, or what our course of action would be if we could not have any zmq_proxy layers between client and server. Our redirector would probably have to become an actor that has sockets that connect are connected to each client and are able to instruct them to disconnect from the current server and connect to another (specific) one. We'd also have to figure out a way to synchronize this so that all clients are fully disconnected from the first server before any start connecting to the second. Also, it would sound like this layer would have to speak a different zproto protocol than the main one we have implemented for the main flow of client/server messages, adding another zproto model to maintain. Again, I'm not afraid of change, but I just wanted to bring up a case where multi-hop request/reply was (IMO) an elegant and simple solution and the alternative would actually be adding complexity. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
