[zeromq-dev] Load balancing REQ/REP sockets
Brian Granger
ellisonbg at gmail.com
Thu Mar 18 13:13:44 CET 2010
Martin,
> Yes. The meachism intended for this kind of thing is "queue limits"
> mechanism recently ported from 0MQ/1.0.
This looks like it may do what I need, but I want to understand this better.
> You can set ZMQ_HWM socket option on a socket, specifying max number of
> messages it can hold. Once the limit is reached for specific connection it
> stops accepting new messages and load balancing skips it in the round-robin.
- Do all socket types have both an incoming+outgoing queue?
- Does ZMQ_HWM affect the socket's incoming queue or outgoing queue or both?
- In the XREQ + multiple REP socket situation which side do I set HWM on?
I have set HWM and LWM to 2 in the XREQ + multiple REP situation. The
XREQ can keep sending messages, but where do they go? It sounds like
the XREQ holds the messages in its outgoing queue?
> However, the number of requests "on the fly" can be pretty high. There can
> be messages in the sender's queue, in secder's TCP tx window, on the network
> (queue on a switch etc.), in receiver's rx window and in receiver's queue.
This makes sense. But where in all of this is the HWM enforced?
Receivers queue?
> What you are speaking about is making it work in lock-step fashion, i.e. no
> new message is sent until the reply is received. This should work on a REQ
> socket. If it does not, it should be fixed.
Yes, I think the standard REQ is working as expected.
> With XREQ socket the situation is a bit more complex. The user can send many
> requests without waiting for a reply. Some of the requests are routed
> through a single connection. At the end of the connection there may be
> another load-balancer, such as zmq_queue. If it worked in lock-step fashion.
> The second load-balancer would be completely useless as there would be at
> most one request processed at a time.
Yes, I can see that what I propose doesn't fit well with this
situation. Let me see if I can understand HWM and get it working for
my situation.
Cheers,
Brian
--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
More information about the zeromq-dev
mailing list