Would Asyncronous TCP networking be a better option for a dedicated server with up to 32 players playing at the same time in C#?

Question

Currently I'm planning to design a dedicated server in C# for an XNA game where up to 32 players will be able to connect at the same time. I have had experience in networking with System.Net, but I've not had to deal with quite a large player count before.

I know from heart that creating and destroying threads (especially one for each player) is not going to be a good idea, and I'm unsure whether or not to use a ThreadPool due to the "wait in line when no threads are available" nature. So, I've decided (pretty much as my only last option) to use Async to handle the large client count.

But I'm still unsure whether or not this is a wise choice, or if I should be using something else to suit my demanding needs.

Apologies if this question sounds bleak, but I'm pretty stumped - help much appreciated!

Answer 1

If the limit of the game really is 32 concurrent users and perhaps a handful of observers, then threads is alright, especially if you find them easier to code with than callbacks. (You'll have to coordinate access to shared data structures appropriately, and the complexity of this may outweigh a corresponding event-based design.)

I probably wouldn't even bother with a thread pool for just 32 concurrent users.

The limitations of threads for throughput shows around 100 threads (depending upon implementation details, of course). If you're never aiming for 100 simultaneous users (which would be a pretty lightly loaded IRC server, for example) then there's no need for the asynchronous event-model unless you and your team are more at ease with the event-model.

Answer 2

What suits you depends on the load you're planning. The most performant solution is usually considered to be a thread pool of asynchronous processors, but that can easily be a gross overkill. Choose the simplest solution that can do the job.

Answer 3

The async approach is strong when the server is I/O bound. Fewer resources will be required while waiting for I/O.

The threads approach is strong when the server is CPU bound. It easily scales to multiple cores or CPUs.

With 32 users, I would cautiously recommend going for threads, at least until async support is ready for prime time in .NET. Just use thread safe structures included in .NET for all inter thread communication and don't code your own and you should be ok. If you decide to code your own, experience tells me that you're probably worse off since even the slightest mistake may cause random errors that are very very hard to track down.