On Fri, 20 Dec 2013 16:18:52 -0500 Lindley French <[email protected]> wrote:
> Yes and no. In general, yes, you're absolutely right. On the other hand, if > you don't mind opening a new TCP connection for each transaction (not > always ideal, but not always bad; it depends), then a successful TCP close > is equivalent to a transaction ack. > > I'm starting to think a *lot* of reliability protocols built on top of TCP > could be done more efficiently if TCP could expose some read-only > information about its internal ACKing.... > > > On Fri, Dec 20, 2013 at 4:13 PM, Stephen Hemminger < > [email protected]> wrote: > > > On Fri, 20 Dec 2013 15:01:04 -0500 > > Lindley French <[email protected]> wrote: > > > > > The problem, in my view, is that normally you can trust TCP to get your > > packets through intact. > > > > Applications only know it made it to the socket queue, not that TCP ever > > sent it and got > > an acknowledgment or that the remote application got the message. To do > > reliable communication > > you need an end-to-end acknowledgment. This doesn't have to be on a > > per-packet basis but > > on a per-transaction basis. Think of what SCP/FTP do for file transfer. > > TCP close is not a synchronization point. The OS may decide to drop unsent, unacknowledged data there is no guranteed it got ack'd and even less assurance that the server read it. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
