Wojtek Meler writes: > > 2. It reports all unsent and unacknowledged data. [...] > I'd like (2). I have a problem with network equipment - peer always read > data it received, but sometimes router breaks the connection. > > I'd like to resend unacknowledged data on next connection.
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. 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? > Another use is to implement lingering in userspace. In single-threaded > server it is not desirable to hang on socket close. 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. -- 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]
