Detecting unexpectedly closed sockets

[Alex Tweedly]

At 17:10 16/10/2004 -0700, kee nethery wrote:


>On Oct 16, 2004, at 4:27 PM, Alex Tweedly wrote:
>
>>At 21:24 16/10/2004 +0200, Tomas Franzén wrote:
>>
>>>Dar, Xavier, Björnke,
>>>
>>>Thanks for your suggestions.
>>>
>>>I will let the server send a ping command to the client, and let the 
>>>client respond.
>>>When the server hasn't received a ping for a while, it considers the 
>>>client gone, and vice versa.
>>
>>If it were me, I'd make the client send the "ping" and the server 
>>respond. It's equally effective for keeping track of connections, and 
>>keeps the "sense" of initiation and reaction right (for my way of 
>>thinking of client/server).
>>
>>And I'd be traditional, and set it up so the keep-alives should happen 
>>every N seconds - and the server only assumes loss of connection if 3 * N 
>>seconds have elapsed since the last ping was received. You might even 
>>allow clients to have different keep-alive timer values (various reasons 
>>why you might want that), and then they should pass their timer value to 
>>the server, so it can use the appropriate time-out logic. (And possibly 
>>thereby avoid a potential future bug if you need to change the time-out 
>>value and operator error leads to it being configured differently between 
>>the two ends).
>
>I concur with Alex.
>
>Since you own both the client and the server I agree with Alex except I'd 
>make it 3.5 * N so that you don't kill the connection just as the keep 
>alive from the client comes in.

Indeed, 3.5 * N could be a better value to use - but I did say I was 
"[going to] be traditional [...] and use 3*N"

There's a long tradition of protocol specs specifying 3*N (RIP, IGRP, BGP, 
etc. all do this) and either other parts of the specification and/or 
implementations find a way to avoid the problem of timing out just as the 
next one arrives (either using jitter as specified by BGP, or 
implementation details as commonly used in RIP).

If there is any likelihood of synchronization (e.g. if all students respond 
to some command from a teacher, then you might find they all send their 
keepalive N seconds later), then it's a good idea to use some jitter value 
on the timers.  For example, use a timer of X*N seconds, where X is a 
random value between 0.75 and 1.0 [lifted from BGP's spec]. If you do that, 
then it's practical to use a timeout of 3*N, since most of the actual times 
will be reduced from N by the jitter.

-- Alex.