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

Michel Pelletier pelletier.michel at gmail.com
Fri Mar 30 17:27:32 CEST 2012


I suppose you could use PUB/SUB with subscriptions, I don't know
enough about your topology or message patterns to be sure.  The
advantage would be if you needed to do 1 to N transmission or messages
or N to 1 reception.

-Michel

On Wed, Mar 28, 2012 at 9:27 AM, Andrei Zmievski <andrei at zmievski.org> wrote:
> Okay, will give that a try. Is there a reason why I couldn't use PUB/SUB
> sockets for this interaction?
>
> -Andrei
>
>
> On Tue, Mar 27, 2012 at 6:37 PM, Michel Pelletier
> <pelletier.michel at gmail.com> wrote:
>>
>> If not getting a timely response is an exceptional condition, then you
>> can throw away your REQ socket, create a new REQ socket, connect it
>> and proceed from there as if it were new.  If it's a common occurrence
>> then you can do ROUTER<->ROUTER and track the state of requests
>> yourself.  REQ and REP enforce a simple state, if you need a more
>> complex state tracking, then you can implement it yourself with
>> ROUTER.  The way I think of ROUTER is exactly like the hardware device
>> of the same name, you tell a router's send() where to send the data,
>> when you recv(), it tells you where it came from.  given that
>> information you can track your own requests and timeouts for every
>> given connected peer yourself in a zmq_poll() loop.
>>
>> -Michel
>>
>> On Tue, Mar 27, 2012 at 4:35 PM, Andrei Zmievski <andrei at zmievski.org>
>> wrote:
>> > Michel,
>> >
>> > Thanks for the example. However, from what I understand, this pattern
>> > does
>> > not allow process A to re-send the request in case it has not received
>> > the
>> > response after a certain amount of time, because REQ sockets don't allow
>> > multiple messages?
>> >
>> > -Andrei
>> >
>> >>
>> >> 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
>> >
>> >
>> > _______________________________________________
>> > zeromq-dev mailing list
>> > zeromq-dev at lists.zeromq.org
>> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> >
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> 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