[C++] High Performance Server Engine

[wolfulus]

Hello guys, some of you know me from MuOnline section, and know too that I'm working on a MuOnline emulator...

I've started developing my first prototype of the emulator some years ago... 2006 I started in VB6 (what a newbie choice, but, I was just starting with the server thing) then I switched to C# in 2007, and reworked the emulator in 2008 (still in C#)

This year, I've started the C++ one, but it's too hard to setup a TCP server properly in C++, but since I'll develop it to work only under Windows, I've started learning the whole IOCP concept, since there's no libraries over the internet that really makes easier to work with the IOCP engine under C++, and things like that... I coded my emulator, which finally made me happy, coz it finally shows monsters walking, path finding, the items finally shows on the player and blablabla... So I stopped for a while, and the idea has come: why not making a easy to use library, for people that wants to develop high performance servers with C++?

The project finally started!

It'll support many things that servers must have, like:

- Memory Management
- Connection Management
- Network I/O control
- Custom protocol specifications
- Support for custom events (signals/slots)
- Broadcasting and Broadcasting channels (not yet implemented)
- Connection filtering (applying rules like a firewall)

I'll be releasing a "getting started" guide soon, with a little client/server game prototype (coded in C++ too with ClanLib)
You can see the screenshot on the website.

This is the project website:

Hps Framework

The whole project is developed from scratch by me.

I'm accepting suggestions of what to add on it tough.

Feedbacks are welcome!


ChatServer using the server engine:
http://img838.imageshack.us/img838/6052/63679532.png

GameServer using the server engine:
http://img241.imageshack.us/img241/4180/gamey.png

[MentaL]

[inumedia]

Interesting. Do tell how you manage the network IO?

[wolfulus]

Interesting. Do tell how you manage the network IO?

Basically you set a size for a pre-allocated I/O buffer for each connected client (NetBuffer), and two classes (NetWriter, and NetReader) will manage the input/output trough the NetQueue interface, keeping it safe to work over IOCP engine.

Here's the main code for that.

Hps Framework

If I understood right what you asked, this is it.

[jMerliN]

Looks a bit over-engineered. You learned how to use OOP incorrectly.

[wolfulus]

Looks a bit over-engineered. You learned how to use OOP incorrectly.

Oh! Sorry about that! But... theres a patch subimission page here:
http://hpsframework.codeplex.com/Sou...loadPatch.aspx

can you do it the right way, please?

[jMerliN]

Oh! Sorry about that! But... theres a patch subimission page here:
http://hpsframework.codeplex.com/Sou...loadPatch.aspx

can you do it the right way, please?

Nah, that wouldn't be very productive. That's like the developers of CVS saying "well just submit a patch to make our system not suck." Yeah.

[wolfulus]

Nah, that wouldn't be very productive. That's like the developers of CVS saying "well just submit a patch to make our system not suck." Yeah.

sorry if I sounded like that, what I mean is that I'm open for suggestions, then you can tell me what to change, add, or remove. Of course it doesn't mean that I'll do whatever you say.

Ok?

[inumedia]

I have to agree with jMerliN. This seems wayy too over-engineered. Given, it does seem like it'd be handy to have to cut back time on the beginning phases of developing a server it also seems like you'd have to read a lot of the documentation before actually starting to use it first.

[wolfulus]

I have to agree with jMerliN. This seems wayy too over-engineered. Given, it does seem like it'd be handy to have to cut back time on the beginning phases of developing a server it also seems like you'd have to read a lot of the documentation before actually starting to use it first.

I can assure that the time you'll spend learning the library will not affect negatively any development part of your project (maximum of 30~40 minutes to read, and implement a test server when learning, and maximum of 15 ~ 20 if you already know how to use it)... there are just 3 classes that you must really know how to work with to start using the library at its mid-full power. The other classes are just utilities that will help the developer during the process...

You'll see when I first release the getting started guide.

-----

I've just released the first version of the library... you can download it here:
http://hpsframework.codeplex.com/releases/view/54388

[penihop]

who are you people to judge his work? have you people done anything bigger, better than his work? do you people have programming education?
no, it is not over-engineered at all. if you find it difficult, i guess you need to read the manual.
for 4 years in C++ i've learned that everything must be perfectly tuned and predicted. "over-engineered" is good thing in every case, but "over-complexed code" is not, in most cases. take a look in any popular open-source network-server code.

the only thing he can do now is to make a template of few functions, to help newbies.

Basically you set a size for a pre-allocated I/O buffer for each connected client (NetBuffer), and two classes (NetWriter, and NetReader) will manage the input/output trough the NetQueue interface, keeping it safe to work over IOCP engine.

Here's the main code for that.

Hps Framework

If I understood right what you asked, this is it.

good job, i have created something similar for Linux.
few questions:
1.what is the maximum number of reader/writer threads?
2.what is the recommended number of reader threads per 1000 clients? i understand it depends on the data processing routine, but if excluded what would you recommend so we don't have more than 2ms processing time of that 1000 clients?
3.and what is the maximum number of clients supported?

[Kreain]

Oh, penihop, You do not know what you just said, Inumedia + jMerlin are fucking insane coders, trust me.

[jMerliN]

who are you people to judge his work? have you people done anything bigger, better than his work? do you people have programming education?

I'm jMerliN, nice to meet you. Yes and yes.

no, it is not over-engineered at all. if you find it difficult, i guess you need to read the manual.

I didn't say it was difficult. I said it was over-engineered. 70% of the stuff there is completely unnecessary. And the design is amateurish and basic from the first asynchronous thread-pool based designs that were about when IOCP/epoll/kqueue became popular. It turns out this isn't the really important part towards efficiency, and it doesn't scale to memory or horizontally very well. I'm not saying it's bad, though. I usually reserve that for the browser clones around here. Actual effort and some intelligence is present so it'd be rude otherwise.

for 4 years in C++ i've learned that everything must be perfectly tuned and predicted. "over-engineered" is good thing in every case, but "over-complexed code" is not, in most cases. take a look in any popular open-source network-server code.

I've been coding in C++ for ~12 years now. The design here is more common in Java code and esp. from people who learn Java as a first language and read those terrible Java books with their horrible take on OOP (you know how things are good in moderation? Well let's say these books are like the 500 lb fat guy who didn't understand fattening foods are good in moderation, except for OOP).

good job, i have created something similar for Linux.
few questions:
1.what is the maximum number of reader/writer threads?

This is OS-specific, there's no reason to put a limitation like this in code. Generally the answer is "when you run out of memory" because threads require stack space and a kernel-level object to store state information.

2.what is the recommended number of reader threads per 1000 clients? i understand it depends on the data processing routine, but if excluded what would you recommend so we don't have more than 2ms processing time of that 1000 clients?

1 thread can easily handle the I/O from 1000 clients. The design of the system is completely up to what you do with threads between I/O. There is no general answer. If the code you're writing implements a lot of CPU-intensive work in the handlers, you'll probably need more threads. And you should avoid at all costs performing I/O outside of the IOCP in a thread. Adding more threads is generally going to degrade performance as it increases the likelihood of context switches.

As a rule of thumb, though, you would want 1 thread per core available to your application sitting in the IOCP queue. It's best if you assign an affinity on these threads as well.

3.and what is the maximum number of clients supported?

There is also no general answer to this. The software doesn't have a limit (well there's no need for one). It's almost always limited by hardware. Memory, CPU, bandwidth available, all of those are generally going to be the bottleneck, so you'd want to stress test whatever project you make on a production server to see what the limits are in that case. If the software doesn't implement things properly, however, the inefficiencies introduced may artificially bottleneck the hardware -- this is where profiling and optimization comes in. It's very easy to handle 20000 simultaneous connections that aren't very bandwidth intensive and has been easy for over a decade. It really depends on what you're doing with the connections and what kind of hardware is running it.

[penihop]

I'm jMerliN, nice to meet you. Yes and yes.



I didn't say it was difficult. I said it was over-engineered. 70% of the stuff there is completely unnecessary. And the design is amateurish and basic from the first asynchronous thread-pool based designs that were about when IOCP/epoll/kqueue became popular. It turns out this isn't the really important part towards efficiency, and it doesn't scale to memory or horizontally very well. I'm not saying it's bad, though. I usually reserve that for the browser clones around here. Actual effort and some intelligence is present so it'd be rude otherwise.

No question about it. you have a great reputation over RZ.
if 70% of the stuff is completely unnecessary right now, but there is a tiny chance someone wants to use it in the future, doesn't seem like over-engineered, its engine after all. he can't guess what the users may want.

I've been coding in C++ for ~12 years now. The design here is more common in Java code and esp. from people who learn Java as a first language and read those terrible Java books with their horrible take on OOP (you know how things are good in moderation? Well let's say these books are like the 500 lb fat guy who didn't understand fattening foods are good in moderation, except for OOP).

but the guy made it open-source, things will get better.

12 years of C++? so you have started coding from 1998, when the standard was published? never seen any bigger, legal software from you. a programmer from 12 years must have a portfolio and website, do you have ? just asking :)

This is OS-specific, there's no reason to put a limitation like this in code. Generally the answer is "when you run out of memory" because threads require stack space and a kernel-level object to store state information.

are you sure there are no limitations? or... can we really use it to that point where it only depends on RAM and CPU?

1 thread can easily handle the I/O from 1000 clients. The design of the system is completely up to what you do with threads between I/O. There is no general answer. If the code you're writing implements a lot of CPU-intensive work in the handlers, you'll probably need more threads. And you should avoid at all costs performing I/O outside of the IOCP in a thread. Adding more threads is generally going to degrade performance as it increases the likelihood of context switches.

adding more threads can also minimize the lag (better sync.) when 1 player is running around 500 others, inside a mmorpg for example.

As a rule of thumb, though, you would want 1 thread per core available to your application sitting in the IOCP queue. It's best if you assign an affinity on these threads as well.

i don't think so. neither do commercial servers. nobody plays by the rules these days.

There is also no general answer to this. The software doesn't have a limit (well there's no need for one). It's almost always limited by hardware. Memory, CPU, bandwidth available, all of those are generally going to be the bottleneck, so you'd want to stress test whatever project you make on a production server to see what the limits are in that case. If the software doesn't implement things properly, however, the inefficiencies introduced may artificially bottleneck the hardware -- this is where profiling and optimization comes in. It's very easy to handle 20000 simultaneous connections that aren't very bandwidth intensive and has been easy for over a decade. It really depends on what you're doing with the connections and what kind of hardware is running it.

are your answers specific to this software ?

Q. 1,2,3 were for wolf to answer, he knows his work better.

Oh, penihop, You do not know what you just said, Inumedia + jMerlin are fucking insane coders, trust me.

i don't really see what their insanity has to do with coding. I used to behave like jMerlin, but i stopped because there is no point, i was just a bit more angry and proud of myself, and it was obvious.