Detecting unexpectedly closed sockets

[Tomas Franzén]

On 2004-10-17, at 18.10, Alex Tweedly wrote:
> 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.

Thanks for the info.
What would be a good value for N? That is, how often should I send a 
keep-alive?
The server should be able to handle many (preferably MANY) clients at 
once. Still, the teachers need to get feedback about the disconnected 
state of the student as soon as possible.
In wireless environments, where students carry around their laptops and 
run out of power, the connections may be unexpectedly closed quite 
often.

Does anyone have experience in handling tons of clients at once with 
Rev? Got any tips?
Thanks.

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

I'm listening to Prodigy - Action Radar