[zeromq-dev] Load balancing REQ/REP sockets

Brian Granger ellisonbg at gmail.com
Thu Mar 18 13:13:44 CET 2010


> 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.



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