Here is one way I might do it....
When the command is recieved, the command is put into an object where the
command, the IP or other info about the sender of the command is passed into
the constructor of the object, and inside the constructor there is code to
store the time of command reception, and the other info into variables then
store it in the pool.
When its time to execute the command, get the object and check to see if it
is too old to process and if so, send a message to the sender that the
server was too busy to execute the command and to try again.
Once you are past that point, you have this command object reception time,
that you can work with to perhaps utilize some sort of user defined event
that aborts the current command and sends a message that the command has
timed out, and then dispose of the command object or whatever you wish to do
with it.
Also, on the internet, I remember something about packets already having a
built in lifetime, you might be able to utilize this functionality rather
than re-inventing the wheel.
"Jeff" <it************@hotmail.com.NOSPAM> wrote in message
news:uW**************@TK2MSFTNGP09.phx.gbl...
IDE: VS .NET 2003
OS: XP pro sp2
I'm developing a server application, clients will connect to it over the
net and start different tasks....
When people sends a command to the program, the command is first placed
into ThreadPool for await processing...
Here is the what I'm having problem with:
I want to implement some kind of a timeout functionality, so if a task
takes too long to perform the user will be notified that a timeout occured
on the server... I'm not sure how to implement timeout, because I must
time the task from the server receive the task and put it into the
threadpool and await processing... while it is in the threadpool it's
waiting to be processed, and as far as I know, if a timeout happens while
it's still in the threadpool it will not be triggered because it isn't
assgined processor power...
Please give me some tips on how to implement this functionality
Jeff