I'm highly inexperienced in terms of network programming, as the wording of my question will no doubt reveal:
Is it possible to use many servers via horizontal scaling (like Wikipedia and Google), to support a single-server MMO?
Using multiple servers to provide the muscle for a single instance of the world, could horizontal scaling be used to support 100,000 concurrent players? Even more?
I don't fully understand how this works, but I'm simply curious if large-scale single-shard worlds are possible (if not via horizontal scaling, then by some other method)?
Thanks in advance for the clarification!
Horizontal Scaling for a Single Shard MMO
WoW also does this IIRC (they auctioned off their old hardware for charity, and had 4 blades per realm, per region (US/EU)). I would be surprised if any large-ish MMO didn't do this. It's usually much cheaper to run a few lower-power servers than a single super-server (that internally often behaves like several smaller servers anyway). I think a relatively common way to do this is to divide the game world up into regions based on expected population density (i.e. a server could hold 5 regions with 1000 people, or 1 with 5000; numbers for demonstrative purposed only) and only talk between the servers when something gets close to traveling between regions. They also probably have a data storage server who's purpose is to store only relatively long term info, like inventory, stats, and the occasional reference position in case something crashes, allowing plenty of players online without stressing the data server too much (a request a second per player is nothing to most modern hardware, especially if they're data reads and even more so if you batch multiple player reads into a single request. Most players aren't going to need a read every second anyway).
All the large MMOs do some kind of sharding. However, it is almost never true horizontal sharding. In EVE, a single system where players can dock is a single process. In WoW, a single dungeon instance or game zone is a single process. In each of these systems, you can't be in one physical process on one machine, and, say, cast a spell on another user in another physical process on another machine.
The closest you get is systems that do transparent migration -- map areas of the world to servers, and as you get close to a border, create a shadow on the other end; once you pass the border, switch roles between shadow and master, and as you move too far away from the border, the original-master-now-shadow can go away. Interactions between players on different servers happen between a master and a shadow.
No matter what your server partitioning scheme is, the problem is that the "everybody wants to be with everybody else" situation leads to n-squared interactions. If all players got into one big dogpile, they'd all pretty much be dependent on the actions of everybody else. This means N-squared growth in the cost of a single CPU, or the cost of networking, or the cost of some other limited resource or combination of resources, at least in aggregate.
Military simulations actually often do exactly the kinds of horizontal sharding you suggest, but at the individually simulated entity level. A tank simulator, a figher jet simulator, and an enemy model can each run on a separate system, and a shared network is used where everyone broadcasts their updates so everyone else can see it. The two main limiting factors here are the display capabilities of each entity (displaying an army of men coming towards you will tax any graphics card,) and the network (doing packet broadcast for all the entities will saturate the network at some point.)
The closest you get is systems that do transparent migration -- map areas of the world to servers, and as you get close to a border, create a shadow on the other end; once you pass the border, switch roles between shadow and master, and as you move too far away from the border, the original-master-now-shadow can go away. Interactions between players on different servers happen between a master and a shadow.
No matter what your server partitioning scheme is, the problem is that the "everybody wants to be with everybody else" situation leads to n-squared interactions. If all players got into one big dogpile, they'd all pretty much be dependent on the actions of everybody else. This means N-squared growth in the cost of a single CPU, or the cost of networking, or the cost of some other limited resource or combination of resources, at least in aggregate.
Military simulations actually often do exactly the kinds of horizontal sharding you suggest, but at the individually simulated entity level. A tank simulator, a figher jet simulator, and an enemy model can each run on a separate system, and a shared network is used where everyone broadcasts their updates so everyone else can see it. The two main limiting factors here are the display capabilities of each entity (displaying an army of men coming towards you will tax any graphics card,) and the network (doing packet broadcast for all the entities will saturate the network at some point.)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
