Detecting unexpectedly closed sockets
alex at tweedly.net
Sun Oct 17 16:29:49 CDT 2004
At 20:25 17/10/2004 +0200, Tomas Franzén wrote:
>What would be a good value for N? That is, how often should I send a
Tricky question - I wouldn't make any guesses without more info - see
>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.
Can you define "many" and "MANY" ?
(i.e. 50 v 500 v 5,000 v 50,000 ....)
>Does anyone have experience in handling tons of clients at once with Rev?
>Got any tips?
[ I don't have that experience with Rev - any tips I give are
general-purpose, network protocol or distributed algorithm tips. ]
Questions (to help answer how many seconds should N (keepalive timer) be)
(sorry if these are repeating info you gave earlier in the thread ...)
1. are you using TCP (open socket) or UDP (open datagram socket) ?
2. if TCP - do you open a connection per transaction (cf most HTTP / www)
or open one and keep it open for multiple transactions (e.g persistent
connections, as added in HTTP 1.1) ?
2a. (if persistent connection) does the server close inactive TCP
connections to preserve its TCP connections (most servers will only be able
to have a limited number of TCP connections open simultaneously)?
3. how many transactions per second (or per minute or per hour - whichever
is appropriate) would a typical teacher and a typical student be involved in ?
4. probably most important - how quickly do you need to be able to respond ?
5. what kind of failures are you trying to detect ?
- loss of power, network, etc.
- student disconnecting deliberately (playing hooky :-)
6. what kind of response will be made when a loss is detected ?
what order of magnitude time-frame is involved ?
(i.e. machine speed, human speed, school administration speed ?)
if you were doing UDP transactions with a need for machine-speed response
and "many" <= 50 - then you might make N as small as 1 second (but more
if you were doing TCP with a new TCP connection per transaction (and hence
per keepalive), and many <= 5000 and a typical response would be the
teacher walking somewhere to react, I'd make N be 60 seconds.
if it's hard to answer the above questions ahead of deployment, then make N
somewhere between those two (5 and 60) and easy to change, and see what
More information about the use-livecode