[zeromq-dev] REQ/REP for possibly async comm?

Michel Pelletier pelletier.michel at gmail.com
Tue Mar 27 01:27:07 CEST 2012


You can use non-blocking ROUTER on a poll loop and REQ or REP on the
other end, that way you can handle requests and their responses as
they come and as you compute them, respectively.  Whether to use REQ
or REP only matters for whichever end starts the conversation.

The LRU pattern documented in the guide has a good implementation of
this pattern with REQ->ROUTER->REP.  It doesn't sound like you need
the actual LRU part of the pattern, just the ROUTER->REQ part.  See
the code for an example how to use a ROUTER socket in non-blocking
mode in a poll loop to handle out of order patterns like A then B
requests but you respond B then A.

Start here and read it a few times. :)

http://zguide.zeromq.org/page:all#Least-Recently-Used-Routing-LRU-Pattern

-Michel

On Mon, Mar 26, 2012 at 4:08 PM, Justin Karneges <justin at affinix.com> wrote:
> I wondered about this as well.  I want to make a worker that does remote
> method calls, and it would expose a REQ/REP interface that other workers would
> use whenever they want to make a remote call.
>
> Since the work bottleneck is time (waiting for remote server responses), I'd
> prefer the worker use asynchronous sockets rather than waste many threads on
> synchronous sockets that spend the majority of their time idle.  However, I
> also want to be able to respond to requests out of sequence (e.g. receive
> requests A, B, but then respond to B before A), and I think this breaks the
> REQ/REP pattern.
>
> On Monday, March 26, 2012 03:21:08 PM Andrei Zmievski wrote:
>> I have two processes that need to exchange data. Process A has to perform
>> time-critical work, but also needs to obtain some configuration data from
>> process B. Initially, I considered using REQ/REP sockets since it's a
>> roundtrip query, doing something like on A:
>>
>> initialize work unit
>> if (previously sent request)
>>    check response from B
>>    if (still no response after 30 seconds)
>>       send config request
>> else
>>    send config request
>> finish work unit
>>
>> The problem I see with REQ/REP is that they work in lockstep and that B may
>> not reply in a reliable fashion. Thus, I wouldn't be able to send a new
>> config request until I heard back from B.
>>
>> Is it better to switch to PUB/SUB or DEALER/REP scheme here?
>>
>> -Andrei
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



More information about the zeromq-dev mailing list