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 _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
