OK, noted.
On Thu, Feb 5, 2015 at 6:55 PM, Joe McIlvain <[email protected]> wrote: > 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
