[zeromq-dev] Async replies?

[Conrad Steenberg]

On Sat, 2009-10-24 at 18:25 +0200, Martin Sustrik wrote:
> 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 
> way.
> 
> 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.

This happens to be my use case. You're right that it can get quite messy
if built out to it's logical complex extreme :-)

In the abstract my application is similar to a job scheduler that
receives job submissions and sends status updates to the submitter as
the job goes through it's lifecycle (e.g. queued, running, failed,
done).

Sure, the submitter can poll for the status of the job periodically, but
it would result in a lot of traffic and a more complex requester.

Atm the application uses zmq-1 as a convenient, fast two-way pipe that
takes care of networking complexities for me and I was looking into
using zmq-2 in the same way.

Thanks for answering my question, I didn't mean to disrupt your
weekend :-)

Cheers,
Conrad

> 
> 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.
> 
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev