[zeromq-dev] RPC design pattern

Joe Holloway jholloway7 at gmail.com
Wed Apr 21 18:00:22 CEST 2010

On Mon, Apr 19, 2010 at 3:11 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> 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.

I agree with your points and the authors of that RFC even noted that
setting those parameters requires a bit of a gentlemen's contract.
I'm asking here mainly so if I publish my investigation in this space
I can articulate what is or isn't possible.  Here I would just be able
to say RFC 2782 is potentially a nice solution for doing service
discovery but you'd have to ignore load balancing hints in the DNS
records to get the most out of 0MQ.

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

I suppose you have the same problem if you are trying to implement
RPC-style transactions on top of any queuing technology?  I think I
still get confused because the API appears to be socket-oriented as if
you are making a direct socket connection, but then there's really a
queuing layer in the middle.  As you noted earlier, a timeout would be
a good solution as long as there's no ambiguity as to whether or not
the message was processed.

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

Specifically as it relates to RFC 2782, there are a couple items off
the top of my head that could be addressed (just brainstorming):

1) A translation scheme to/from RFC 2782 style names (e.g.
_zeromq._tcp.example.com 5555) into 0MQ style address strings  (e.g.

2) Pros and cons of static registration (RFC 2782) vs. dynamic
registration (DNS-SD).

3) Can a client detect that a service is local and switch over to
inproc/ipc transport for optimization (or does the 0MQ kernel already
attempt this?)


As you can probably tell from the above discussion, I'm coming at this
mainly from the perspective of RPC over TCP style messaging since
that's what I'm most familiar with.  I haven't really given much
thought to other messaging patterns or broadcast protocols.

More information about the zeromq-dev mailing list