.NET Game Server

Question

i've a question over here regarding the .Net framework technology and the gaming server. supposely, i've a few game machine acting as a client and i want to connect those client machine to a gaming server, do you guys think it is good if i develop the server application using the .NET framework?

the client machine is also developed in dotnet technology. what if i expand my server to a few servers running concurrently, is that be possible if i employ .Net framework on my game server? what .Net technology should i use, .Net Remoting, XML web services, COM+, MSMQ or any suggestion?

one more important factor here is the performance wise. i want the communication between the client and the server to communicate fast and efficiently without long lagging time.

the purpose i want to expand to a few servers is because if in case one of the servers down or shutdown for servicing, i still can have my application running without interrupting the game process which is mission critical and real-time.

are there any kind soul out there done such a settings before? if yes, what do you guys feel about it? best, good, worse or worst to employ the .Net in the game server?

i sincerely appreciate all the .Net and game developer expert to give some feedback for me here.

thanks,

Answer 1

I don't think I have the sort of domain knowledge needed to answer this, but I want to give it a shot anyway, and Maybe I'll ask some questions which help tease out the right answer for you.

Is .Net the way to go? I don't know. Communicating with DirectX? - pass, sorry.

Are the clients and the server on the same LAN? Are they connecting over the web? For sheer performance I woudl a ssume .Net Remoting. For comms in general you might want to consider the WCF, as you can change the way you communicate pretty much by a change in config (queuing to web services, for example). Having said that, to get teh most out of something like queuing you may need to be careful about how you actually design the end-points.

You talk about scaling out the server? I guess you'll be wanting to hit some sort of load balancer, with multiple nodes under that? This might be helpful: http://www.codeproject.com/KB/IP/remotingdesigndecisions.aspx

Answer 2

In order for any sort of scalability for a game server, you need to utilise UDP for communication (which .NET supports, see UdpClient).

This article might point you in the right direction: Multi-Threaded Game Server Browser

Answer 3

I'm not sure that a standard .Net approach is going to be the way you want to go...

Each .Net technology you mention has a measurable setup and teardown cost associated, and WCF is among the worst of them. If performance is your goal you need to be talking to the ports directly instead of using a standardized wrapper to handle them. I'd even argue that if performance is truly key that you need to be looking at a straight C function instead of a .Net language. (Some will certainly disagree with me, but I've found that dynamic languages such as Ruby and Python to be pretty dang quick as well)

The other question that will come into play is you data backend. If it's all in memory then running multiple servers means that you'll have to employ some sort of caching mechanism such as memcached to keep your data all synced up. If you are going to use a database I would suggest using several ports, one that is connected to your database and another that is strictly memory based. The advantage you gain is that data that doesn't require databases can run in a memory space that runs as fast as the computer will run and the process doesn't have to wait on costly database connections.

WCF/.Net Remoting/COM+/etc are all great for line of business applications where a 1 second turnaround isn't going to kill you, but in a realtime environment where every millisecond counts you need to be able to manage the entire communication stack from the time you receive the first packet until you close the connection. Every .Net communication stack I've used in realtime environments has added almost 100ms to every request. By cutting out the middle man and dealing directly with the client (ie, reading the stream straight off of the port and then sending the stream directly to the port) I cut that cost out and get that time back. When you deal with tens of thousands of requests per minute that time becomes very important.