[zeromq-dev] Notes from a hackathon

AJ Lewis AJ.Lewis at quantum.com
Thu Feb 5 20:41:24 CET 2015


On Thu, Feb 05, 2015 at 09:55:10AM -0800, Joe McIlvain 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.

Is the plan really to drop multi-hop routing?  That seems like a bad
idea if that's what's going on...we're using multi-hop routing quite
extensively.  What's the replacement?  I haven't been able to figure
that out from this thread.

Can't the non-multipart message routing headers handle multiple hops?

Thanks,
AJ


> 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
> zeromq-dev at lists.zeromq.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.zeromq.org/mailman/listinfo/zeromq-dev&k=8F5TVnBDKF32UabxXsxZiA%3D%3D%0A&r=R2zWNFHLVImAo2qABlJKsHZpXtrP7rtLmoGaa3CV1do%3D%0A&m=tk9%2BVPVImoQCUleK2mCioAxfwpoubrnPjTpb%2FekLDM4%3D%0A&s=5be95c7bb0d7cd94b67d0afede00fa794b6c6b041e1abd7f464f84acfb2d9e2c

-- 
AJ Lewis
Software Engineer
Quantum Corporation

Work:    651 688-4346
email:   aj.lewis at quantum.com

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.



More information about the zeromq-dev mailing list