[zeromq-dev] 0MQ 2.0 Model Question: Continued.

Steven McCoy steven.mccoy at miru.hk
Wed Oct 21 09:25:12 CEST 2009

2009/10/21 Martin Sustrik <sustrik at fastmq.com>

> Yup. That's the standard way of doing the thing on client side. Now
> consider the server side: You have to extract the inbox address from the
> message, store it somewhere. Once the reply is ready, the address should  be
> attached to it so that 0MQ knows which client to send the reply to. What
> kind of changes to API are required here?

There is a matching SendReply call taking as arguments the request message
and the reply message.  The function takes the reply subject out of the
request message and sets it as the send subject of the reply.  It's a
trivial wrapper of this form:

onMsg (request) {
  Msg reply;
  reply.setSendSubject (request.getReplySubject);
  ::transport.send (reply);

> Actually, my feeling is that most users would appreciate simple load
> balancing among N worker threads with no need for user to mess with reply
> addresses etc.
Rendezvous has a system of events, queues, and queue groups to work with
sorting incoming messages into different subjects and priorities,
and dispatchers for processing in different threads or thread pools.

Load balancing and fault tolerance across processes is handled by either a
distributed queue or alternative configurations of which there are many to
suit different needs.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20091021/02aa612c/attachment.htm>

More information about the zeromq-dev mailing list