I've been reading a number of articles on TCP socket class, listeners and threading, but none have really explained the limitations of what they are presenting. My current game project's scope has the potential to serve 150-200+ players on the same server system. From what I gather, this is not possible using a Thread-Per-Listener object implementation to deal with each client. Does this include threads who are currently waiting for the TCPListener class to receive data from a client, or does the thread sleep during this time? I am still trying to understand the basics of implementation, is this a correct process for the server to deal with clients? 1. Single Listener thread which accepts all client's input 2. Above thread spawns a new thread to process specific client's input 3. Listener thread closes connection with client 4. Spawned thread sends response to client, then closes itself, disconnecting from client Is it efficient to constantly disconnect and reconnect with a client in this fasion? How do I prevent slow connections from bogging down the rest of the players if I implement this sort of process? Thanks, Cyric

200 open threads with 200 TCP sockets is doable on modern PC hardware. It's not the best way to get performance, but it won't get in the way. 1,000 would be a really bad idea, though (and 200 isn't so hot, either, just not as bad).

Creating new connections and new threads all the time would be MUCH heavier load than just keeping the threads/connections open while the client still wants to communicate.

I would recommend a single-threaded solution, and a state machine. Most servers are memory bound, anyway, so multiple CPUs on the same memory bus wouldn't help much with load. Of course, I'd also recommend using UDP, rather than TCP, if you want to scale to large number of users, as you only need a single thread and a single socket, not loading the kernel with zillions of open sockets.