lifetime of a physically disconnected tcp socket without keepalive

Question

On a TCP connection without the keep-alive option, if I physically disconnect the wire - so no FIN/ACK possibility, will this socket happily accept all my application data, put it in the send buffer and try to send it forever?

And if not, when and how it dies = which errors will be returned to my application sending small chunks of data? we talk Linux and c.

Thank you

Answer 1

If the socket is sending, (1) eventually the send buffer will fill up, so the next send call would block, and (2) eventually TCP would time out the send attempts due to receiving no ACKS and reset the connection, and deliver an error to the next send call.

Answer 2

On the send side, it would fill up the send buffer since it cannot send the data to the client. The outgoing packets (as much allowed by the receive window and available space in the send buffer would simply sit in the send buffer and TCP would end up retransmitting them.

URL: http://linux.die.net/man/2/send

If the socket is blocking, then the send() call would simply block and the application would end up waiting for this call. If the socket is non-blocking, then the send() call would return -1 and set the errno to EAGAIN or EWOULDBLOCK.

Setting SO_KEEPALIVE is certainly the main option for such sockets. In addition, you could also play around with tcp_retries1 and tcp_retries2 values mentioned in /proc/sys/net/ipv4/. When the sender kills the connection due to tcp_retries2 limit reached, the next blocking call would return a value of -1 and the errno would be set to ETIMEDOUT. Please note that these options are applied globally to all sockets on the box -- so we should use it with care.