[zeromq-dev] Async replies?

Martin Sustrik sustrik at fastmq.com
Sat Oct 24 18:25:35 CEST 2009

Hi Conrad, PJ,

>>> What I mean by async replies is simply replying to messages sent by a
>>> REQ application to a REP application in a different order than received,
>> That is being currently talked about in a couple of other threads.
>>> or sending a message REP -> REQ without receiving a request first.
>> I was wondering about that too. But that would take it into the realm
>> of Brokers, Clients with registered identies and such, no?  0MQ 2.0
>> seems to be aiming towards a much simpler model.
> It does, yes. However, if you look at the code (src/rep.cpp) you'll see
> that all it would take to implement this is associating the appropriate
> socket (in the zmq sense) with every message so that any replies can be
> sent back to the requester.

Yes, it's easy to implement, however, implementing features just because 
they are easy to implement doesn't seem to be the best way to go. Rather 
I would prefer having consistent and real-world-use-case-backed sematics 
for each socket type.

As for async REQ/REP there are several flavours:

1. Almost obvious and long acknowledged scenario of single-threaded 
client and multi-threaded server. Technically, to make this scenario 
work, you need a special "device" often called "shared queue" that 
gathers requests from multiple clients and load-balances them between 
several worker threads. It also routes replies back to corresponding 
requesters. If the "shared queue device" exist as a stand-alone process 
and repliers become individual applications rather than threads, what 
you get is standard broker-based implementation of a SOA service. Note 
that in this scenario the REQ and REP sockets work the same way as they 
do now (i.e. alternating sequence of requests and replies). All the 
magic is done in the "shared queue device".

2. Allowing REP to send replies out of order. The functionality could be 
implemented, however, I am not sure I can thing of a use case for it 
other than having to support legacy application that simply behaves that 

3. Multiple replies to a single request. I've seen this being used but 
the semantics are pretty messy IMO. How is the requester going to know 
how many replies it's going to receive? To implement it in a sane 
fashion the messages on the wire would have to be tagged by BEGIN/END 
flags. Still, what is the whole thing good for? And if we want to have 
multi-part replies why not allow multi-part requests? Etc.

4. Streaming of messages - sending replies to a different application 
("downstream") rather than back to the requester. This scenario is 
absolutely valid but out of scope of the current discussion AFAIU.


More information about the zeromq-dev mailing list