[zeromq-dev] Notes from a hackathon
Joe McIlvain
joe.eli.mac at gmail.com
Thu Feb 5 18:55:10 CET 2015
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.
More information about the zeromq-dev
mailing list