hi! I have a question about network architecture. i found that online game will run serveral programs in the serveral servers. e.g one program one server to handle partly activities of the game. But how to divide a game into serveral program? My question is what criterias to divide a game. My member suggest that use function to divide.e.g Server A handle Trading System, Server B habdle Battle System. But if i want to stop the Map01''s Trading system, i stopped the ServerA, all the trading system will stop. <--i think it is a good idea but how can solve this situation. Do you have any reference or idea or recommendation?

Ok let''s see if I understand you:

You want to run an Online Multiplayer RPG on more than one server although you want all users to be able to exist in the same game world???

Well the main point in this is that one server simply hasn''t got enough bandwith to deal with 10000 users or so. And that is the root to the problem - bandwith. You could have one server doing all BattleStuff and another doing all TradingStuff but what if all 10000 users wants to fight all the time and no one is trading? Then only one of your two servers are working and you have a bandwith problem all the same!

In order to achieve a multiserver online game you need to find large data blocks within the game that only seems to be used by certain users. Think of your Game World as a giant Excel spreadsheet - thousands of numbers and letters. Now each player changes these numbers and letters as they play the game - they build houses and fight etc. What if we now discovered that 50% of the players only seem to use the lower part of the spreadsheet and that the other 50% only uses the upper part? Then it would really simple! We let Server 1 handle the upper part of the spreadsheet and 50% of the users and Server 2 handle the other part. And where do we find these data blocks? Well of course it differs from game to game but most commonly it''s in the geographical represantion of the Game World!

So if your RPG is a simulation of Earth then let Server 1 handle everything that happends in Asia, Europe and Africa, and let Server 2 handle everything that happends in America, Australia. Because - is it likely that a player that is in Europe will build a house in America? no. It is important to divide the Game World between the servers so that

1) the Servers will have to send as little data as possible
between each other
2) the Users will need to access the other Servers as little as possible
3) so that the bandwith is equally used on all servers

Generally the easist way to achieve this in an RPG is to divide the world geographically between the servers. Of course the players should be evenly spread out in the game world.

If you decide to divide the world geographically then you''ll need to have some kind of "dead zone" that both Servers share in the game world. When a player that is connected to server 1 enters this zone he is then automatically connected to server 2. if the player then continues out of the dead zone and into the zone controlled by server 2 he will already be connected and there will be no delay. Of course the dead zone should be an area where very few users reside - for instance open sea.

If you want to make it more advanced you could make the zones dynamic so that the servers adapt. If a certain geographical area becomes popular among the players and a server needs to unload some of its players to another server it could for example give up Australia to Server 1...



hifive!
/soul8o8

Hello !

I develop multiprocessed programms & server. For MMO server need consist from 3 part
1) World server (Contain only data, shared access to another server for requesting them) (WS)
2) Processed server (PS)
3) Network server (NS)


Exmaple: Client changed item, command send to NS. NS send "packet" about changed to nearest PS server. PS server processed this and send update for all NS and WS. In NS need know update info about items for connected client.

In other words you had
1) A database
2) Game servers and
3) a custom gateway/router

I was actually thinking about this the other day.. would it be better to have a single PC on the LAN which delt with the database?

So in my case i would have a server PC (connected direct to net and the LAN, and a dedicated database server on the LAN and have the game server send all database info to the DB computer. Would that actually speed things up ? and should the calls to the DB (on the seperatre PC) be on a dedicated thread so to not delay the main thread while comunicating with the DB server ? I have currently decided to not write all updated character/world data to the DB as the game is played so as not to slow the server, but if it was done this way would it speed it up enough for me to be able to not worry about the cost of writing data to disk and do it on the fly ?

thanks

~tim

I believe the common way to do it is something like this.
You have one fast server exposed to the internet, all this server does is basically look at the message headers, and redirect them to a "game" machine. The way it possibly does this, is it just takes the player ID and broadcasts the packet onto the LAN and the server that is handling that player will accept the packet. It may also keep a routing table of sorts, with a table of playerID''s referenced with the server they''re currently on.
You have many game servers, dynamically load balanced, or a server assigned to certain zones, or however you decide to do it, these perform the actual game rules. It retrieves needed data for the rules from the DB which may be several servers with a router, operates on the data and then sends data it needs to back to the DB. It may need to lock the data in the DB, depending on what the data does.
If you set up your servers as zones, then it would probably be ok to store frequent objects in memory, as there is no possibility of another zone requiring the same data as your zone (with very few exceptions, such as online messaging or an online bank, item storage etc.) However, there is a danger that if the server crashes, and you don''t frequently update the data in the DB a lot of gameplay would be lost. So sure keep things in memory, but run a system that backs those values up either every 5-10 seconds(?) or every time they''re update, whichever happens less often.
If you use dynamic load balancing, you would need to lock/unlock the data in the DB because it is possible that multiple servers would try and access the same data (for instance, 3 players may be attacking a monster, due to load balancing the 3 players are all on seperate servers, the data for that monster would need to be locked/unlocked when a server tried to update it after a player attacked it).
Hope that helps a little....

This really depends on how many players you intend to service. MUDs can service hundreds of players on a single server process that handles login, authentication, database and game logic. Commercial MMOs use server clusters to run thousands of server processes over many CPUs. So, how many players are you targeting?

The idea is to be scalable. You can start out with one server process for all game logic, another process for player authentication, and then the Database, all on one physical server. As you get more players, create a "lobby" process that keeps the IP addresses of all other server processes. This will allow you to launch as many game logic servers as you want, and still only maintain a minimum number of login and database servers. Since the bulk of game traffic will involve game logic, that is really the most important piece to seperate.

To list an exact formula for how to seperate game processes would be too specific to a particular game to be of any use to you. All of the current systems are flawed anyways, find something new.