Wojciech Meler writes: > James Carlson wrote: > > That seems to me to be pointless. If the router (or some other > > failure) breaks the connection, there's just no way to know what data > > were actually eventually read by the peer application and what data > > were lost in the accident. Merely knowing that the peer TCP > > implementation has sent you an ACK does _not_ mean that you know that > > the peer application has received or will _ever_ receive that data. > > But for me it is enough to know that data has arrived in peer system > buffers. If client application didn't fail (segmentation faults or so) > it will read its connections so it will receive that data. > > Is it possible that read call can't read acked data ?
Yes, it can happen in two ways. One is if you get TCP RST, generated either by the peer or by some misconfigured system on the network (i.e., either "connection sniping" or a common stateful firewall failure mode), and the other is if you do in fact crash before issuing the read. I don't see how you can rule those out. And the TCP RST scenario (causing intentional buffer flush) seems particularly devastating. > > Is there a TCP-using application in which silent data loss is an > > acceptable result? > > In this application data loss is not possible - message can be only > doubled and it is acceptable. Yes, it is possible. If you use TIOCOUTQ and it reports to you that data have been acked by the peer, *BUT* that peer application never gets a chance to read that data, then when you reopen your connection, you'll never send that data. You will falsely believe that the peer has seen the data because TIOCOUTQ tells you so. This will result in silent data loss. It sounds like a design error to me. > > That's easy -- use shutdown(fd, SHUT_WR) and then read from the > > socket, or use poll or select for read. The shutdown(3SOCKET) call > > will cause the stack to send TCP FIN. When the peer closes the > > socket, you'll get a zero-length return from read(2). > > > > That mechanism, unlike TIOCOUTQ, is portable and works reliably. > > It doesn't work reliably when peer is behind firewall which has timeout > for half closed connection and crowded networks. Sure. The best you can do there is set up a timer and _assume_ that the data never made it to the peer. It doesn't mean that you have to "hang" or that it can't be done. > Moreover it can cause > data loss and hangs on the client side because fin is sent along with > last data packet which can be lost. The last data packet can't be "lost." It will be resent. If the peer never acks it (and the FIN), then it'll time out, and you'll get a ETIMEDOUT. If it does ack the message and the FIN, then you'll be stuck in FIN-WAIT-2 state until the peer closes his end. You'll then get a zero-length read. This actually tells you *more* than the TIOCOUTQ mechanism could -- it tells you that the application read to the end, saw the end of file, and then did an orderly close on its socket. The only way that could be a problem is if the peer application itself closes the socket without bothering to read the last message that was enqueued by TCP. If that's the concern, and the peer can't be taught to close with linger 0 (RST) for failure cases, then you *definitely* need application level acknowledgment. I see no good way around it. > Anyway in environment I work such feature is desired. I'd love to use > solaris because of dtrace, but I want support as much users as it is > possible and I can't force them to use specyfic protocol/client or to > move to other network. Does TIOCOUTQ on a socket work anywhere _but_ Linux? I think you've created a requirement that essentially rules out any sort of portability. -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
