3

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!

Marlon
  • 19,924
  • 12
  • 70
  • 101
seandewar5
  • 299
  • 1
  • 3
  • 10
  • 3
    You haven't given us enough information. You haven't told us if it's a real-time game, or if it's a turn-based game, etc. – jason Jan 21 '12 at 01:24
  • The game is going to be a real-time 2d shooter, with a destructable "tile" based world. So, I will be expecting quite the bit of server load at times. I only plan on ever sending the full world data when the client connects/map changes, and I plan on only sending changes to the world throughout gameplay. – seandewar5 Jan 21 '12 at 01:28

3 Answers3

3

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.

sarnold
  • 102,305
  • 22
  • 181
  • 238
  • That answer really suprised me (in a positive manner), because all I was hearing throughout the internet was people talking about how constantly creating and destroying threads to send / recieve data is bad; especially when there are 32 clients connected. Are there any extra things I would need to consider when dealing with threads for the a server, or would it be as simple as any other threaded server such as chat servers? Thanks. – seandewar5 Jan 21 '12 at 01:38
  • 1
    Well, I wouldn't suggest creating a new thread for every communication with the user -- but a thread per user is alright. User connections are relatively long-lived, anyway. I'm not aware of anything else you'd need to be cautious of, but [Joachim's recommendation](http://stackoverflow.com/a/8949991/377270) to use the "standard" thread APIs makes a ton of sense. – sarnold Jan 21 '12 at 01:46
2

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.

Joachim Isaksson
  • 176,943
  • 25
  • 281
  • 294
  • Thank you for your response, if only I could of picked two answers two answers to my question, I would of also picked yours too, as seeing that the server will be more CPU dependant, you've further helped me choose threading over Async (which is hopefully the right direction as you guys have stated), I'll compensate with a +1. – seandewar5 Jan 21 '12 at 01:51
0

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.

vines
  • 5,160
  • 1
  • 27
  • 49