Detecting unexpectedly closed sockets

Tomas Franzén tomas at lightheadsw.com
Sun Oct 17 14:25:40 EDT 2004


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


More information about the use-livecode mailing list