   C# Multiplayer Server
  Hi there i am currently pondering on what is a good way to setup a Game Server for around 50 to 100 people and whether or not multi-threading is really a good solution as it may one day or another being more then the amount of connections above stated. Some further details:Programing Language: C# or C++ Would prefer C# but if there are reason against or pros or cons please feel free to let me know.Game Servers Purpose: Is to support a small mud and also be the code base for other none mud style games the muds purpose is to be more of a learning curve on go architecture for game servers.To Multi-thread or not to multi-thread:Multi threading seems like it could be a good solution when dealing with many players however it seems to me (because i lack multi-thread experience) that dealing with player interaction and events may become more complicated and accessing data from another thread can cause issues of course as well so for instance.One player moves onto a sector that another player is on ergo i have to update both players clients to reflect the change that has occurred. The problem here is do i just update every client as much as possible which can seem a little unreasonable as far as bandwith is concerned or do i some how try to get the moving client to update it needless to stay this part of the server is going to perplex me for quite some time and any and all advice is welcome.More or less a rough diagram of what a good server would look like and how it is probably best to setup a flexable and stable server.I know i am asking a lot of question here to be honest but anything helps thanks a head of time and regards Jouei.   
  C# is actually a very good choice if you want to leave your server running for longer periods of time due to .NET's compacting garbage collector. IOCPs are supported as well now, so it can scale to thousands of users when done right.Most servers work with some kind of time frames. All client packets that arrived until the beginning of a time frame (containing player movement, any interactions like picking up objects and so on) are processed and the server's state of the world is updated accordingly. These time frames can be very rough with most of the seemingly fluid world being clever client-side interpolation.Then the server sends the updates relevant to each client back. Bandwidth is usually more of a concern than processing power, so in general, only things that have changed in the immediate vicinity of the player are sent. Typically these packets contain instructions like "player X began picking up Y at time frame 12345".Multithreading can be used in various ways here. Integrating incoming client updates into the world can be done in parallel for any updates where there's no chance that they overlap. Accepting incoming client packets, doing preliminary checking and sending acknowledgements back to the clients can also happen before the server uses its upstream bandwidth to send its updates back.If you have a peristent world, it's usually a good idea to update the database in the background, too, because databases are a huge bottleneck. It can get a bit tricky if the world is a moving target, but if you use fine locking granularity for your game world, the impact is manageable.Regarding threading, it's a difficult topic in itself, especially considering that you can easily construct code that seems to work but fails about 1 in 1000 times randomly. Read up all you can on thread synchronization, memory barriers and race conditions before embarking on such a journey. There's an excellent free online book about threading in C# here:http://www.albahari.com/threading/