MMO server architecture proposition

[iindigo]

Here's a little something I've been thinking about. I don't know much about the limitations imposed by the WoW client or MMO server design in general, so that's why I'm running this by you guys. Please enlighten me as to if this is feasible or just plain stupid.

A big problem even for both official and private servers is how a single bug, a memory leak, or excessive load in one area can bring an entire continent (world server) down. What I'd like to know is why can't this be dealt with in the same way web servers like ngnix deal with it. To those unfamiliar, nginx uses a number of worker processes (defined in its config) that handle serving sites to viewers instead of dropping all responsibility on one process. This means that if something goes wrong and a worker crashes, the other workers can go on and a new worker can automatically be spawned to take the crashed worker's place. All continues smoothly and users never have a clue that there was ever a problem.

I am unsure of how Trinity is structured, but it seems to share the same problem that Blizzard's servers do; a tiny bug or memory leak can bring the a whole continent down.  As such, it might be beneficial for Trinity (or another emu) to adopt an adapted multi-process model… perhaps something like the image below.



Under this model, the server spins up at least one process for each zone. During times of high load (like city raids or world events), additional processes can be launched to meet demand. Zones with no players within viewing distance could have their worker process shut down or suspended, based on frequency of player visits. NPCs that traverse multiple zones would be the exception, carrying a special flag in the database and being handled by an ever-present global worker.

This setup would save resources, appropriating them to the areas they're most needed in. It also means that if someone runs across a bug that triggers a crash or memory leak, only that zone will go down while the rest of the continent is unaffected. Finally, it also allows for better scalability - worker processes could be spread across multiple virtual machines or servers, meaning that if a server's population starts pushing hardware limits one can balance its load across two or more machines instead of having to set up a second separate, empty server and redirect new players. On a smaller scale, it could also mean that you could get respectable performance cheaply through chaining together the old Pentium 4 boxes sitting in your closet.

Thoughts?

[schlumpf]

Blizzard does this, even arcemu was able to split onto multiple servers, iirc.
There are still bugs crashing the whole thing, as communication is required.

Sandboxing and splitting is the way to go, yes, but it rarely really works as there are hell a lot of little problems. Browsers should be a good example of sandwiching being used for plugins, JS, even single tabs. And still, they are crashing and freezing as a whole.

[iindigo]

Ahh, I wasn't aware of that. Guess the whole original post was pointless then, haha!

I do realize that WoW server emulators are considerably more complex than web servers, but why is it so much more difficult to make them efficient and stable? The most stable (and somewhat popular) private servers I've been on crash at least 2-4+ times a day. The only ones that don't are those with little to no population.

[schlumpf]

There is no real difference. Web servers have really different requirements though: They serve files directly or do some cgi call, where the worst is that application crashing, resulting in a 50* error. Most of the time, the language used is also some dynamic, horrible scripting language, like PHP, which will just fail silently, showing half of the page or something.

A game server will be communicating via some non-standard protocol with a game client, thus has no peer review of the protocol, leaving some holes in there. Also, often, error checking is left out or lax to get better performance. E.g., if you validate every position in any movement package being above ground, that will just be too much. Thus, you have a lot of holes where bad input data will result in broken behavior. On emulated servers, this error checking is even worse, as they don't know the proper protocol, therefore can't do the correct checking and may even result in bad behavior with proper input due to unknown values.

Also, they are amateurs, hacking shit together instead of doing it properly, which will be the reason for most of the crashes.

[akspa420]

I believe the whole reason why blizzard is doing the virtual realms now is to basically do something similar to the OP. Enterprise-level sandboxing on a server-by-server basis is the norm nowadays. Blizzard is just playing catch-up with 'merged/virtual' realm options.

[Sina]

I'm not sure, if this is thread necromancy or if it fits at all to the topic buuut...

I heard a lecture today about task based game servers. Isn't this in a way what you suggested, indigoo?
Also, it was said that WoW is still using multi thread servers, which weren't that good.

Since I'm first semester, i don't really have an idea how a game server works inside. : D
Just wanted to share this information with you.


Little question: In what category would the emulators fit in? Single threaded (I don't think so), multi threaded or task based?