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

Michel Pelletier pelletier.michel at gmail.com
Sun Apr 1 16:07:01 CEST 2012


True, I also should have pointed out, when you do ROUTER to ROUTER you
usually must set the identify of at least one peer.  If both ends have
an auto uuid, then neither end knows the id of it's peer and nothing
can be sent in either direction unless you use some other out-of-band
channel to synchronize peer ids.

-Michel

On Sun, Apr 1, 2012 at 3:02 AM, Schmurfy <schmurfy at gmail.com> wrote:
> 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
>>
>
>
> _______________________________________________
> 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