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 ?
In other words, the best you could do with such a feature would be to implement an unreliable application that sometimes gets confused and silently loses or corrupts user data. What's the point of doing that? 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.
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. 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.
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.
Regards, Wojtek _______________________________________________ networking-discuss mailing list [email protected]
