Handling Timeouts in a Socket Server

I have an asynchronous socket server that contains a thread-safe collection of all connected clients. If there's no activity coming from a client for a set amount of time (i.e. timeout), the server application should disconnect the client. Can someone suggest the best way to efficiently track this timeout for each connected client and disconnect when the client times out? This socket server must be very high performance and at any given time, hundreds of client could be connected.

One solution is to have each client associated with a last activity timestamp and have a timer periodically poll the collection to see which connection has timed out based on that timestamp and disconnect it. However, this solution to me isn't ver开发者_如何学Cy good because that would mean the timer thread has to lock the collection whenever it polls (preventing any other connections/disconnections) for the duration of this process of checking every connected client and disconnecting when timed out.

Any suggestions/ideas would be greatly appreciated. Thanks.

---

If this is a new project or if you're open to a major refactor of your project, have a look at Reactive Extensions. Rx has an elegant solution for timeouts in asynchronous calls:

var getBytes = Observable.FromAsyncPattern<byte[], int, int, int>(_readStream.BeginRead, _readStream.EndRead);

getBytes(buffer, 0, buffer.Length)
     .Timeout(timeout);

Note, the code above is just intended to demonstrate how to timeout in Rx and it would be more complex in a real project.

Performance-wise, I couldn't say unless you profile your specific use case. But I have seen a talk where they used Rx in a complex data-driven platform (probably like your requirements) and they said that their software was able to make decisions within less than 30ms.

Code-wise, I find that using Rx makes my code look more elegant and less verbose.

---

Your solution is quite OK for many cases when the number of connected clients is small compared to the performance of the enumerating the collection of their contexts. If you allow some wiggle room in the timeout (i.e. it's OK to disconnect the client somewhere between 55 and 65 seconds of inactivity), I'd just run the purging routine every so often.

The other approach which worked great for me was using a queue of activity tokens. Lets use C#:

class token {
    ClientContext theClient; // this is the client we've observed activity on
    DateTime  theTime;       // this is the time of observed activity
};

class ClientContext {
    // ... what you need to know about the client
    DateTime lastActivity;   // the time the last activity happened on this client
}

Every time an activity happens on a particular client, a token is generated and pushed into FIFO queue and lastActivity is updated in the ClientContext.

There is another thread which runs the following loop:

• extracts the oldest token from the FIFO queue;
• checks if theTime in this token matches the theClient.lastActivity;
• if it does, shuts down the client;
• looks at the next oldest token in the queue, calculates how much time is left till it needs to be shutdown;
• Thread.Sleep(<this time>);
• repeat

The price of this approach is a little, but constant, i.e. O(1) overhead. One can come up with faster best case solutions, but it seems to me that it's hard to come up with a one with faster worst case performance.

---

I think it is easier to control timeout form within the connection thread. So you may have something like this:

// accept socket and open stream
stream.ReadTimeout = 10000; // 10 seconds

while (true)
{
    int bytes = stream.Read(buffer, 0, length)
    // process the data
}

The stream.Read() call will either return data (which means client is alive) or throw IO exception (abnormal disconnect) or return 0 (client closed the socket).