[zeromq-dev] REQ/REP for possibly async comm?
Schmurfy
schmurfy at gmail.com
Sun Apr 1 12:02:50 CEST 2012
be careful with setting identities, there are known problems with them, you
may want to check messages about issue #325 fix.
If you have connection issues between the two process one may end up with
an auto generated identity instead of the one you wanted with latest code
or in the released code you can get an assertion failure which will crash
both your server and client ;)
On 30 March 2012 18:24, Andrei Zmievski <andrei at zmievski.org> wrote:
> ROUTER-ROUTER seemed to work. I just set the socket identity on process
> B to something known and then process A uses that to send the messages. The
> socket in process A is anonymous.
>
> -Andrei
>
>
> On Fri, Mar 30, 2012 at 8:27 AM, Michel Pelletier <
> pelletier.michel at gmail.com> wrote:
>
>> 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
>> >
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120401/bc8f3b22/attachment.htm>
More information about the zeromq-dev
mailing list