Yup. It's kind of ironic that TCP is viewed as a "reliable" protocol when in practice it barely provides it at all. What it does provide is automatic redelivery attempts which is quite handy, along with in-order delivery and flow control. These are great things, but an application desiring reliability will need to know about data receipt as well.
HTTP, SMTP, SIP, XMPP, etc, all provide their own ways of indicating successful data receipt, independent of TCP. It's redundant, but it's the way of the world. On 12/20/2013 01:18 PM, Lindley French 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] <mailto:[email protected]>> wrote: > > On Fri, 20 Dec 2013 15:01:04 -0500 > Lindley French <[email protected] <mailto:[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. > > > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
