[zeromq-dev] GSoC ideas inquiry

Yin Qiu qiuyin at gmail.com
Mon Mar 14 17:05:04 CET 2011

Hi Martin,

Sorry for my delay.

在 2011-3-10,21:25, Martin Sustrik 写道:

>> Also you are saying "multi-priority". Then how are priorities assigned 
>> to connections? I mean, is the priority of a connection manually 
>> specified by client programmers or calculated adaptively at runtime?
> The idea was to allow load-balancer to treat connections with different
> priorities. Say:
> s.setsockopt (ZMQ_PRIORITY, 1);
> s.connect ("tcp://hostA:5555");
> s.setsockopt (ZMQ_PRIORITY, 2);
> s.connect ("tcp://hostB:5555");
> while (true) {
>    ...
>    s.send (msg);
> }
> In this case all the messages would be sent to hostA, unless it's
> unavailable or overloaded. Only in such case would the messages be
> routed to hostB. That kind of thing is very useful if you want the
> messages to be routed to your local service (e.g. on the same LAN) and
> fail over to a different service instance (e.g. located on a different
> continent) only in case the local one is unavailable.
> To have a look at the load balancer code,  check src/lb.hpp and src/lb.cpp

Thanks for clarifying this. So we are going to support a new option, ZMQ_PRIORITY, which is valid only for 0MQ sockets of types PUSH and (X)REQ. When we do xattach_pipes(), the current value of this option (i.e., priority or preference) is attached to the added outpipe as well. The backend load balancer, which maintains multiple priority lists, then puts these pipes in the right place. In this way, the load balancer selects a pipe to send the message in O(1) time (perhaps with the same find-first-bit-set instruction as the Linux kernel) instead of round-robin. Correct?

>> I have one question which is more about design. Let's take the listener 
>> side as an example. In order to share the underlying tcp socket between 
>> 0MQ sockets, one approach is to use a static structure within the 
>> zmq_listener to keep track of shared tcp listener objects. The listener 
>> pool, which I call it, is responsible for creating listeners, updating 
>> their refcnts, and deallocating them when appropriate. Proper 
>> synchronization should also be taken into consideration when it comes to 
>> concurrent accesses.
>> An alternative may be to delegate maintenance of these listener objects 
>> to the ctx. When a zmq_listener wants a tcp listener, it just asks the 
>> context to return one.
>> What do you think? Or is there any better solution?
> My gut feeling is that the former solution is more appropriate, as in
> the latter case the context would be just a proxy between 0mq sockets
> and listeners, adding an unnecessary level of indirection.

OK. Then I'll try to write some POC code in this week.

Yin Qiu
Nanjing University, China

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110315/79633e57/attachment.htm>

More information about the zeromq-dev mailing list