[zeromq-dev] RPC design pattern

Martin Sustrik sustrik at 250bpm.com
Mon Apr 19 10:11:36 CEST 2010

Hi Joe,

> OK, that part is starting to make more sense now.  I'm playing around
> with putting my service definitions in SRV RR records (actually
> DNS-SD, but same concept). The RFC [1] spells out a load balancing
> algorithm for client programs based on the weight and priority of each
> record.  It's not round robin, but similar.  The idea is that the
> person registering the service knows the attributes of the hardware
> that it's running on and can hint to the client agent that X node has
> more capacity than Y node although they are both offering the same
> service.  Just thinking out loud, but is there a way to provide those
> hints to 0MQ or should we just trust that 0MQ is better at dynamic
> load balancing than we could hope to be using deployment time hints?

0MQ does a dumb load-balancing (round robin). The assumption is that we 
don't know processing capacity of each peer in advance. If a particular 
peer is not able to keep up, it's queue gets filled up and no more 
messages are dispatched to it. Once it processes some messages, and thus 
  empties the queue, we can add the connection back to round-robin.

If we knew the weights in advance (as specified with RFC 2782) we can in 
theory write a load-balancing that would hit the queue limits less 
often. However:

1. Do we even care?
2. User has to manually set the weights = work = increased cost.
3. There's no guarantee that user will set the weights so that they 
reflect the reality.

>> When one of them fails, up to ZMQ_HWM requests is queued for it and once
>> the limit (HWM) is reached it no more request will be sent to that
>> server. Once it gets back online queued requests will be sent to it and
>> load-balancing starts to dispatch new requests to it automatically.
> The part that confuses me about this is in a traditional RPC scenario
> you may be calling services that have side effects or that lack
> idempotence, per se.  You'd want the message to be handled by the
> first reachable service provider and no others.  Unless I
> misunderstand what you're saying, it seems counter-intuitive that
> RPC-style messages would queue up rather than failover to alternate
> instances or fail fast when there are no reachable instances?

The question is: How do you know the instance is reachable. You can 
never tell before you actually get a reply from it. To get a reply you 
have to send a request. That means that at least 1 message (the request) 
is "queued" for delivery to the service with unknown availability. 
There's no way to avoid that.

As for why 0MQ allows more than one message in the queue - it's for 
efficiency's sake. Having at most one message sent to particular 
instance means that processing of requests proceeds in lock-step 
fashion, which can be severely inefficient, especially in scenarios 
where there's non-negligible roundtrip time between client and the service.

> I probably need to go back and read the whitepapers again now that I'm
> becoming more familiar with the concepts.

Please, keep the list posted about your experience with 0MQ and RFC 
2728. The matter is of critical importance for further development of 
0MQ and the more experience we as a community can gather about 
addressing and naming issues, the better.


More information about the zeromq-dev mailing list