Sign in to follow this  
lordcorm

High traffic Game Server (C# vs C++ with Boost)

Recommended Posts

For about the last week ive been going on a 'language/library/engine/framework' tryout spree to try to find the best framework for my Game Server. Currently, Its has come down to C# or C++ (with Boost). ----------------------------------------------------------------------- Looking at the Pros and Cons of a C# Server. Pros: - Faster Development Time - Easier to implement 'modular' support (Class Libraries) - Huge Integrated Framework (.NET 3.0) - Easier for n00bies to jump on Cons: - Slower Performance - Windows Only (Virtualizing with Mono is not ideal) ----------------------------------------------------------------------- Looking at the Pros and Cons of a C++ (with Boost) Server. Pros: - Performance (if programmed correctly) - Will work on any x86/x64 platform. Cons: - Slower development time. - Harder for n00bies to jump on. (Unless they are very skilled in C++) - Although Boost has alot of framework pieces already done, it still is missing some things I need. ------------------------------------------------------------------------- Ive been finding it really hard to make my decision.

Share this post


Link to post
Share on other sites
First, as someone who has done high-performance distributed computing with Mono, I'm somewhat surprised about that "virtualization not ideal with Mono" claim, especially since the needs of a video game are probably not as complex or heavy as those of distributing computing grids.

Second, a game server is something huge, which involves a lot of parts that have no reason to be written in the same language. Some parts, such as the low-level UDP socket manipulation, may indeed deserve to be done in C++, but there's no reason to do the high-level work in C++ (especially since you will probably want to gain a lot of performance through multithreading, which C# supports far better than C++).

Share this post


Link to post
Share on other sites
Personally, my opinion for a smaller team size (i.e. < 10 developers) would be to go with whatever you'd be most productive in. For most people, that's going to be C# by a long margin...

Share this post


Link to post
Share on other sites
"game server" can mean a server for a poker site, or a server for an in-browser 2D game, or a serer for an MMO game, or a server for an FPS, or one of a number of different kinds of servers.

First, asnwer the question: What is your game? What requirements does it have?
Once you know that, you can whittle down the list of available technologies.

Share this post


Link to post
Share on other sites
Quote:
Original post by lordcorm
- Windows Only (Virtualizing with Mono is not ideal)


Sorry, but what? Mono doesn't virtualize anything, .NET/CLR code is assembled on a specific bytecode format, Jitted/AOT'ed later by the mono runtime or the .NET runtime.

Share this post


Link to post
Share on other sites
Quote:
Original post by ToohrVyk
Some parts, such as the low-level UDP socket manipulation, may indeed deserve to be done in C++

Que? The speed of the network is so much slower than the code interacting with the network that at no point in time would the network code be a bottleneck compared to your ability to transmit data, especially if you use IOCP (which C# sockets are inherently built to do when you use the asynchronous method calls such as BeginSend/EndSend).
Quote:
but there's no reason to do the high-level work in C++ (especially since you will probably want to gain a lot of performance through multithreading, which C# supports far better than C++).

So very true also there's the ease with which you can mix managed and unmanaged code, although there are plenty of performance penalties for doing such and so you should be extra sure to profile first before and after you attempt such intermixing...

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603

First, asnwer the question: What is your game? What requirements does it have?
Once you know that, you can whittle down the list of available technologies.


Its actually an MMO Emulator, so i dont expect to have as much traffic as a live commercial server.

The most i expect on a server at the time is 2,000 (and thats not on one zone, but one cluster.)

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
How will you reach 2,000 players and have them all play your emulator all at the same time?


The game im emulating used to be huge, and there are several server communities waiting for a server to be done (there are actually several other teams working on the same game, but not doing too well of a job) that have around 5,000 members on their forums (but only around 500 - 1,500 are active atm).

But yea, ill look into those servers then and see what they did for load distro and session handling then, because im fairly new to C#, but a 2 year veteran of using C++. (which both of the languages are very similar so its not really a problem of learning syntax, just where everything is in the .NET framework, because i never used managed C++.)

Anyway, thanks for the help guys.

Share this post


Link to post
Share on other sites
Quote:
Original post by lordcorm
just where everything is in the .NET framework


That's pretty much what there is to learning a language most all of the time, with the exception of learning a new paradigm. Syntax is something you should be able to pick up within an hour, and be comfortable with within a week.

As for Mono, just because it is different that doesn't mean it is much slower. Mono performance typically is a little slower, but overall still very good. But either way, it is more about how you implement the logic and not the speed of the language itself.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603

Anyway, there was an Ultima server emulator written in .NET a few years back, and I think it did 2,000 users in pure .NET.


Considering that Ultima ran just fine on hardware probably less powerful than most cell phones today, there's even an x86 emulator written in Java apparently running Linux. Guess one could try doing apt-get install java in there...

But perhaps more importantly, emulators and similar software enjoys a luxury more projects never have - the requirements never change. All the assets and design don't nor can change. This leaves a lot of room for optimization.

And there's little emphasis or need for data integrity or reliability, or any of back-end features, account and payment system integration, logging, patching and build system, the development time and resource consuming stuff basically.

Share this post


Link to post
Share on other sites
I am going to suggest C#. As others have said, your network packets are going to be slower then what your code is going to be running. Next, the bane of a server are memory leaks, C# and garbage collection helps prevent that. The time it would take to clean up all the possible memory leaks on a C++ server might kill your whole project. Remember a server needs to do the same things over and over and over again without a leak.

theTroll

Share this post


Link to post
Share on other sites
Quote:
Original post by Antheus
But perhaps more importantly, emulators and similar software enjoys a luxury more projects never have - the requirements never change. All the assets and design don't nor can change. This leaves a lot of room for optimization.


That is true only when you have completed the emulator and have all the data you need to run it. [wink] Until then, any change the retail game server makes could essentially set you back months in your development cycle. Some games are more server driven than others, so for some games, it will always be the case where you have to constantly update your code to be able to keep developing the emulator. I've actually seen a number of games that have implemented game-changing patches to where any work you'd have done would be rendered useless. Hope that team would have a good risk management plan haha!

Games that are not updated frequently or have reached their end of development cycle are much easier to write emulators for since you do not have to worry about such changes, but from what I've seen in the free mmorpg market, there are not many of those. Older mature stable games are the main exception and more to what I'd agree with your comment on.

Quote:
And there's little emphasis or need for data integrity or reliability, or any of back-end features, account and payment system integration, logging, patching and build system, the development time and resource consuming stuff basically.


I respectfully disagree with this point. I've been looking around at others' emulator code on RageZone and was simply appalled by how badly implemented their server code was. The goal of an emulator is not that much different than the goal of the original developers. If the developers ignore the aspects of data integrity or reliability, then their servers will get owned, easily. I would say there is a general lack of understanding overall of those points, but there is an important need for it.

I've seen projects that process single packets at a time (talk about a real bottleneck when you make your code receive one packets worth of data at a time in a TCP stream), have absolutely no memory cleanup (i.e. the project would leak memory so badly it wouldn't be able to run for very long if a lot of players got on), improper sprintf calls coupled with mysql code (just begging for sql injections / buffer overruns), and painstakingly poorly design code to send packets to players (one example I saw would allocate 65kb on the stack N times and compute the packet N times for a send to N clients when only a single stack allocation / packet computation would be needed)

There's just so much to a server that is easily overlooked in these projects that if they were ever able to become a functional server, they would not be able to stay online too long due to how easily exploitable they would be. Retail servers often suffer from the same thing and those are written by "professionals", you can only imagine how an "amateurs" server would be like [lol]. That of course is not to say all emu projects are bad and poorly implemented, because they are not, but I'm talking about a large percentage of them that have opened their code.

My advice would be this. Get something that actually works first, get your emulator going, and only after you have it working should you worry about the "performance" metrics of the core components you are using. From what I've seen personally, most projects do not even get over that hump of getting it all working in the first place, so I think you should worry about a solid core later once you know for sure your project is going to work.

I myself have been working on a C++ based emulator server framework and the network code I feel is solid now, but that in itself was quite a long project and I'm still finding things to fix in it to make it "correct". Using a good solid networking library might be the best approach to handle that aspect on your server. That way, you only have to worry about the server logic, which in itself is a whole other story development wise.

I know the long term effects of my design, it won't be pretty or scale well for a large number of people. However, it allows for very rapid development and takes a unique perspective at how to prototype out a game server. The truth of the matter is, why should I worry about spending a lot of time trying to write an industrial grade architecture that can supports thousands of players, when I can write a much more simple one that can support a few hundred easily and actually have the time to write the emu logic.

When you go and share your project with others, or even if you do not, there are good chances it will be leaked / hacked, so your investment in the 'best' architecture possibly is now lost and in the hands of everyone else. If you write simple, but solid, working code and dedicate on getting things working, then you can go back later on and improve upon the setup to make it better.

Ok, I'm done droning on and on [lol] Just want to say, use what you are most productive with, get it working, and don't worry about performance until you actually have to worry about performance. This is a fun project for yourself and in the process of doing it you will learn a lot, it won't be perfect first few times around.

Share this post


Link to post
Share on other sites
Quote:
but a 2 year veteran of using C++.


Not to burst your bubble or anything, but AFTER graduating college as a comp sci graduate, it usually takes 10 years to become a senior engineer who can actually be called a "veteran." There simply is no substitute for experience.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Quote:
but a 2 year veteran of using C++.


Not to burst your bubble or anything, but AFTER graduating college as a comp sci graduate, it usually takes 10 years to become a senior engineer who can actually be called a "veteran." There simply is no substitute for experience.


I guess veteran isnt a good word i should of used. More like a 2 year 'user' of C++ :P

Anyway, thanks for the help guys. I appreciate it. After looking through alot of SVN's of current MMO Emulators written in C#, im pretty sure thats the route I wanna take.

Share this post


Link to post
Share on other sites
C++ isn't necessarily harder to code in or more unsafe.
If you like C++, just code in C++. If you like C#, just code in C#.

One advantage of C++ is that it allows you to write code as efficient as you want it to be.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
How will you reach 2,000 players and have them all play your emulator all at the same time?

Anyway, there was an Ultima server emulator written in .NET a few years back, and I think it did 2,000 users in pure .NET.


It's RunUO 2.0 ;), i'm a scripter on a Ultima Online italian unofficial shard and we tested it with 900 player and it goes everything well.
The real problem is for the client, when you have all 900 player in the same screen (during a a party), it lags, but it's not a server problem.
RunUO it could be a good example to make big game servers ^^.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this