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!
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.