[Solved] C# Asynchronous Server Sockets – Thread-Safety/Performance (MMO Gaming) [closed]

Question

The first thing I want to mention, since I believe it is answers the root of your question, is that your performance (latency, concurrent connection capacity, etc) is going to be largely defined by the hardware you are running this software on and the network performance for each specific client. Software can improve some things but generally speaking, if your code is well written and understandable by others and contains no bugs, it will perform just fine.

Will your code handle 300 connections concurrently? Yes most likely it can. I do see some potential issues with threading though. One being that you will have a lot of contention when you accept new clients. You also created a vulnerability by waiting between accepts for each client to be fully accepted, a potential for a denial of service attack. A client can stall the connection by requiring re-transmissions of data for each packet up to three times per packet and can wait to deliver each message up to whenever your timeout is (10 seconds?). There will also be a lot of problems with data processing unless the method stubs you have are thread safe themselves once you implement them.

You are using the older asynchronous socket model. It’s a little complicated for what it is. I think that you will understand the event driven model a little better since it is more natural in my opinion. I know that from my experience, either perform just fine. However, I have also found that the new event driven model is a bit faster since you do not have huge garbage collections being done due to over allocation of IAsyncResult objects. The newer model uses methods such as Socket.AcceptAsync and the Socket.Completed event.

Since you are new to C#, I would recommend that instead you should be focusing efforts on writing a simple and clean client/server application that has asynchronous elements. You can do a load test on that and see if it satisfies your criteria for performance in terms of the raw throughput on your hardware. This will reduce the factors in your analysis. I recommend starting with something that can communicate simple text messages back and forth. You can increase the complexity as you gain a deeper understanding of the nuances of threading and network communication in .NET.

One website I recommend you looking into is http://www.albahari.com/threading/, this has a good explanation of the various building blocks for writing multi-threaded code. It’s aimed at people with programming experience, as you mentioned you have. The “advanced threading” section is what I reference often.

The book “Pro C# 2010 and the .NET 4 Platform” by Andrew Troelson (ISBN 1430225491) would be a good start as well. It covers a lot of the language and shows some parallels between C# and other languages. It also covers a lot of .NET which is what most people really need to get a good understanding of before diving into the fun stuff.

Accepted Answer

The first thing I want to mention, since I believe it is answers the root of your question, is that your performance (latency, concurrent connection capacity, etc) is going to be largely defined by the hardware you are running this software on and the network performance for each specific client. Software can improve some things but generally speaking, if your code is well written and understandable by others and contains no bugs, it will perform just fine.

Will your code handle 300 connections concurrently? Yes most likely it can. I do see some potential issues with threading though. One being that you will have a lot of contention when you accept new clients. You also created a vulnerability by waiting between accepts for each client to be fully accepted, a potential for a denial of service attack. A client can stall the connection by requiring re-transmissions of data for each packet up to three times per packet and can wait to deliver each message up to whenever your timeout is (10 seconds?). There will also be a lot of problems with data processing unless the method stubs you have are thread safe themselves once you implement them.

You are using the older asynchronous socket model. It’s a little complicated for what it is. I think that you will understand the event driven model a little better since it is more natural in my opinion. I know that from my experience, either perform just fine. However, I have also found that the new event driven model is a bit faster since you do not have huge garbage collections being done due to over allocation of IAsyncResult objects. The newer model uses methods such as Socket.AcceptAsync and the Socket.Completed event.

Since you are new to C#, I would recommend that instead you should be focusing efforts on writing a simple and clean client/server application that has asynchronous elements. You can do a load test on that and see if it satisfies your criteria for performance in terms of the raw throughput on your hardware. This will reduce the factors in your analysis. I recommend starting with something that can communicate simple text messages back and forth. You can increase the complexity as you gain a deeper understanding of the nuances of threading and network communication in .NET.

One website I recommend you looking into is http://www.albahari.com/threading/, this has a good explanation of the various building blocks for writing multi-threaded code. It’s aimed at people with programming experience, as you mentioned you have. The “advanced threading” section is what I reference often.

The book “Pro C# 2010 and the .NET 4 Platform” by Andrew Troelson (ISBN 1430225491) would be a good start as well. It covers a lot of the language and shows some parallels between C# and other languages. It also covers a lot of .NET which is what most people really need to get a good understanding of before diving into the fun stuff.