On Tue, Jul 13, 2010 at 10:02 PM, Martin Sustrik <[email protected]> wrote: > Brian Granger wrote: > >>> I would say the whole retransmission part has to be inside of 0MQ rather >>> than implementing in on top of it. >>> >>> I like to think about XREQ/XREP as an equivalent of IP in the Internet >>> stack. You send data. Presumably they get to the destination, however, >>> they >>> may get lost occasionally. >>> >>> Therefore, there's a reliability layer on top of it: REQ/REP (or TCP in >>> case >>> of Internet stack) which monitors the replies (ACKs) and in case of >>> problem, >>> manages the retransmission. >> >> Are you suggesting then that all of this be transparently happens >> inside the 0MQ library, so that I don't have to worry about this? > > Yes. The functionality should be definitely part of 0MQ library in the > future. Reliable delivery is one of the big value-adds of MQ-style solutions > after all.
That would be extremely nice. With that, our entire infrastructure could be handled by a simple ZMQ_QUEUE device! >> That would be quite nice! That would require an XREQ socket to buffer >> all messages until it knows they have been handled. The only odd >> thing about the picture is that IP ensures only that packets get >> there, not that the other side replies. In this case, I want to be >> sure that I actually get the reply from the other side. > > Think of TCP rather than IP. It actually solicits the reply from the peer > (ACK), however, it's kind of invisible to the user as there are no user data > bound to the reply. Yes, OK now I see what you mean. Cheers, Brian > Martin > > -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo [email protected] [email protected] _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
