Detecting unexpectedly closed sockets

[kee nethery]

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.

Put a version number into the client and server keep alive packets 
(this is the maximum version keep alive packet I know how to send) and 
have the server respond with a version number (this is the version 
number I want you to send that is within the range of version numbers 
you are capable of OR here is the text message to display to the user 
since I'm not going to support you). Building in a version number for 
the server and client keep alives lets you add additional information 
into the keep alives while being backwards compatible with your 
installed base.

As for potential additional features, of which there are an infinite 
number that you could add without doing any useful work, I'd have the 
client send a keep alive with an incrementing integer (that cycles back 
to 0 when the max value is reached) and have the server return that 
value so that the client understands whether all keep alives are 
getting through. If not, the client might want to increase the value of 
N that it sends to the server and keep it's value of N the same 
(knowing that there is a failure rate).

Also, have the client time it's keep alives based upon the time the 
last server reply was received, not the time when the client last sent 
it. Reason being that if a server is under heavy load just servicing 
keep alives and it takes time to reply because of that load, you could 
have all the clients sending a keep alive at exactly the same time 
which could cause problems for the server. If they delay their next 
keep alive starting from the time they received their last server 
reply, the server is going to spread them all apart just by the nature 
of it being a server and sequentially providing each client with a 
response.

Finally, always keep your keep alive packets to a size small enough to 
fit into one single ethernet packet. Don't exceed that length for 
something as simple as a keep alive.

Ah, network protocol design, fun stuff.

Kee Nethery