Detecting unexpectedly closed sockets

[Tomas Franzén]

On 2004-10-17, at 02.10, kee nethery wrote:
> I concur with Alex.

I agree it would seem more logical to make the client send the 
keep-alive, and have the server respond, when considering the 
client/server relationship. Right now, the client is basically built so 
it can only send requests, and receive replies. In this case, letting 
the client do the requesting of the keep-alive command, would save me a 
lot of work, not needing to modify it both to send and receive new 
commands.

However, I consider the message first sent to be a check if the other 
end is alive, and in that case, it'd seem logical for the server to 
send the initial command, and update its user list according to the 
result (getting a reply or not).

I need the client to receive new commands anyway, so I think I need to 
modify it even if I let the client send the 'ping'.


> 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.

Makes sense.

> 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).

Yes, I do something like this now. I call my protocol RSCP, and it's 
rather human-readable, a lot like HTTP.
It's used for monitoring students in a school. Teachers can keep and 
eye on what they're doing, and take actions based on that.
I call the incrementing number 'Request-Id'. This id can be any 
alphanumerical value, and is generated by whoever sends the initial 
request. It's similar to tags in IMAP.
A sample request might look like this:

RSCP/1.0 AUTH
Request-Id: abc123
Content-Length: 21

myUserName myPassword


... and this could be the reply:

RSCP/1.0 OK
Request-Id: abc123


... which means that the login was successful.

> 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.

Good point! I'll keep this in mind.

> 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.

As you can see, my requests are not very small. A keep-alive might look 
like this, I suppose:

RSCP/1.0 KEEPALIVE
Request-Id: 123

Will this fit into a single ethernet packet? I don't know much about 
this kind of lower level stuff.

> Ah, network protocol design, fun stuff.

Indeed. :-)
In my situation, I use two kinds of clients, the 'master' (teacher), 
and the 'client' (student), and both connect to the main server, which 
keeps track of who is online. Also, the student is a server, too, 
responding to commands from the master. Ah, tricky stuff.

Tomas Franzén
Lighthead Software
http://www.lightheadsw.com/

I'm listening to Cake - When You Sleep