Detecting unexpectedly closed sockets
kee at kagi.com
Sat Oct 16 19:10:34 CDT 2004
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
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
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.
More information about the use-livecode