Re: TCP server does not detect the client network failure

From: Steve Horsley (shoot_at_the.moon)
Date: 08/01/04 

Date: Sun, 01 Aug 2004 14:05:41 +0100

Liz wrote:
>
> Several helpers suggest sending some sort of message that would
> generate a response, a heartbeat type of thing. Can you not in fact
> claim that the last message actually sent performs this function
> since the user expected a response and didn't get one (so an extra
> heartbeat message would not help either.) The complaint is that the
> connection hangs. If I run a packet sniffer on my laptop, I see a
> bunch of messages going back and forth some of which are generated
> by a timeout. Something should be there that will take care of this
> problem. I think it is entirely reasonable that the high level
> user (the java programmer) should expect to get some message back
> or to have an exception. It is similar to using a normal telephone.
> You pick up the handset and expect dial tone. If there is no dial
> tone, you don't expect the user to understand that the voltage on
> his line to the phone company is running at -48 volts and for him
> to put a voltmeter on the line to make sure. Here is another comparison.
> The user is doing IO. Compare to the user reading a file from disk.
> You don't recommend for the user to periodically read a directory
> to make sure the path to the disk is working for the file read.
>
> (ps. Some how, I am now expecting a bunch of static over this.)
>
>

It's layers on layers. Forget the application behaviour for a moment
and think what is required of TCP (none of the layers below TCP do
anything to check that sent data actually arrives).

TCP has the job of getting data from A to B reliably. To achieve that,
all data sent has a sequence number allocated, and TCP requires that
all data sent must be acknowleged by the reciever. To cope with lost
messages, it implements timers and will eventually retransmit any
data that goes un-acknowleged. After numerous retransmissions without
an ack, it assumes the connection is broken.

But take the position of a TCP connection end that has nothing to send:
it just sits and waits for a message to arrive. If nothing arrives,
so what? Wait some more. There's no timeout here that says "nothing
has arrived, the connection must be broken", there's just infinite
patience.

So the ONLY way you can know a connection is broken (at the TCP layer)
is when sent data goes unacknowleged.

If your application wants to be sure that the other end is still there,
it needs to send a message once in a while. You can either implement
a timer in the application waiting for a response, or you can send a
dummy message that gets ignored by the far end application and let the
TCP layer retransmissions figure out that the connection's broken. An
application that is prepared to sit and wait for a message that never
comes cannot blame TCP for not delivering a message that was never
sent, any more than you can blame the postman for not telling you that
Great Aunt Maude has died and therefore won't be writing to you any
more.

P.S. The keepalive socket option tells TCP to send a byte periodically
in a way invisible to the application.

Steve

Relevant Pages