Creating an idle timer

[pink]

I am working with a client/server app pair. What I am looking to do is have a timer that begins will disconnect the client from the server if it is idle for longer than 20 minutes. (Timing does not need to be exact. 20 minutes is just a general guideline)

Here's what I've got and this seems to work...

is there a more efficient method? Does anyone see a problem with it that I might have missed?

Code: Select all

local sIdleTimer, sMessage

on actionPerformed      ----this gets triggered any time a button is pressed
     put the seconds into sIdleTimer
     if sMessage is not empty then cancel sMessage
     send idleCheck to me in 1205 seconds   --yes, I gave it an extra 5 seconds
     put the result into sMessage
end actionPerformed

on idleCheck
     put "Testing" into field "field"
     if (the seconds-sIdleTimer) > 1200 then disconnectMe
end idleCheck

[dunbarx]

Whew.

For a moment I thought you were going to use the "idle" message to query the system clock. Or anything. Avoid "idle" if at all possible.

You code sends a message in time, and check the status of something. Just so. I would caution using the result as the source of the state of the "flag" you created, just because that function is somewhat fragile, like "it" or the "foundLine". I would set a property or load a variable. But, if it works, it works.

Craig Newman

[pink]

This worked out pretty well. Using the results didn't seem to cause any issues.

The reason I added "put the result into sMessage" was so that I could keep track of any pending messages created by this handler. What I found was that actionPerformed gets called so frequently that I ended up having hundreds of pending messages.

Is there another reliable way to get the message ID of the message that was scheduled by the send command?



These questions are just for my own knowledge and curiosity:

is the biggest issue with the "idle" message the fact that it consumes a lot of resources?
and if so, if the idle ticks was set to poll once every minute, would it still be as detrimental to performance?

[sturgis]

If it were me, I'd keep a list of connected clients that includes "the seconds" of their last valid action. Perhaps even an in memory sqlite table.

Then for the checks, you could use a send in time loop, check it every couple minutes. The pseudocode would be something like this..

on newConnection pVar, pvar2 etc -- the required info on the connection
--store the connection info in the in memory db including the seconds
-- the rest of whatever you need here.
end newConnection

command checkConnections
-- grab all records that have stored seconds that are more than 20 minutes old
-- select all records where the seconds field < (the seconds - 1200)
-- go through each line and disconnect the client
send "checkConnections" to me in 30 seconds -- This way, you only ever have 1 message queued.
-- to decrease load, you could also query the db for and do the "send" based on
-- when you expect the next connection to timeout rather than every 30 seconds.
-- If there are multiples coming up around the same time, there might be several
-- very quick succession messages sent, but overall the efficiency gain would be worth it.
end checkConnections

on actionOccured pSocket
-- do whatever the required action is
-- then update the sqlite table with the current seconds
end actionOccured


The only real worry I'd have with this method is if a request comes in as the checkConnections is working. Its possible a connection could be nuked despite having an "under the wire" request come in.

[SparkOut]

Keep it vague and not worry about coincidental actions. Just pop up a dialogue box when the loose idle check time is up, saying "The connection will be closed in 30 seconds... 29... 28..." which is modal and can have a reliable 30 second countdown, or if cancelled the connection can remain open.