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

Andrei Zmievski andrei at zmievski.org
Fri Mar 30 18:24:52 CEST 2012


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120330/2c2c5419/attachment.htm>


More information about the zeromq-dev mailing list