[zeromq-dev] Async replies?
Martin Sustrik
sustrik at fastmq.com
Sun Oct 25 08:24:12 CET 2009
Hi Conrad,
>> 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.
I would say there are two types of messages involved:
1. management (job submissions, cancelations etc.)
2. notifications (status updates)
What about using 2 sockets instead of 1? REQ/REP one for management,
PUB/SUB for notifications? The added value would be the ability to
subscribe to particular subset of notifications. Pseudocode:
socket_t manage (ctx, ZMQ_REQ);
socket_t notify (ctx, ZMQ_SUB);
notify.setsockopt (ZMQ_SUBSCRIBE, "myjob.*");
message_t submission (100);
...
manage.send (submission);
message_t confirmation;
manage.recv (&confirmation);
while (true) {
message_t status;
notify.recv (&status);
...
}
>
> 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 :-)
The wether was pretty gloomy here yesterday. There was nothing better to
do anyway :)
Martin
More information about the zeromq-dev
mailing list