Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I have been learning networking for about 4 months. Wrote a single standalone Multiplayer server and succeeded with authoritative approach. Now I want to extend it by splitting the single server into clusters to allow even more players to log in to avoid latency issues. Now I have protyped the Loadbalancing server and its running pretty good so far.

This is my architecture, I have a master server which acts as a proxy, every sub servers(chat, login, game) connect to the master server as well as all the clients. when a client connects,

Client Request: Send Request -> MS(Master) -> Decides which SS(SubServer) to forward to -> Forwards Request to SS -> SS -> Analyze Message -> Send Response to MS -> Decides which Client to forward to -> Forwards Response to Client

Well, it looks like its going through lots of stages. it takes double the time to process the message than a single server approach. i feel like my model isnt the best or i may be wrong. is there any better model or the one they use in professional games? I still want a Master-SubServer approach.

I just want to clarify that I'm going in the right direction before writing all my codes. Thanks for any answer :)

share|improve this question
    
How many users is this game going to be serving? If it's < 10,000 then you probably don't need this technique, and if it's > 10,000 then you must have the budget to hire some very experienced network developers. –  MarkR Jun 3 '12 at 2:05
add comment

3 Answers

There's nothing wrong or uncommon with your approach. Having proxy servers is definitely useful for facilitating automatic migration from one server to another, for being able to restart servers without the client being disconnected, for implementing encryption or compression on an otherwise untaxed host, for reducing the networking overhead on game logic servers, etc. You will incur a latency penalty and that's unavoidable. But sometimes it is worth it.

The real question is: how do you decide which sub-server to forward a message to? There are two major approaches:

  1. By location - the traditional approach (if you can't fit it all on one server) is to handle different zones on different servers. All the game's logic is available on each server, but each one only handles a small part of the world. This is very simple to implement since each server is identical except for the data and acts like a monolithic server would, but doesn't scale so well if some areas are used much more than others. You can work around this a bit by having multiple zones per server and load-balancing zones across servers, which is useful but tricky. For seamless worlds you might divide the geography up using a grid rather than by arbitrary zones that don't actually exist, but bear in mind that you now start entering into the complex realm of having different servers negotiating with each other over game logic that involves 2 entities on adjacent servers - such as ranged combat, trade, etc. Managing the seamless boundary between 2 areas represented on different servers is one of the main problems facing MMO developers.
  2. By service - some games have different server processes for different aspects of play, such as a Chat service, a Combat service, a Trade service, etc. The logic gets complex in areas where 2 things overlap as 2 or more services need to start exchanging data between them. Imagine that entering combat causes a trade to cancel - the Combat service must send a message to the Trade service to tell it to cancel the trade, and that in turn might have to send messages to the Inventory service to return items to a player's inventory, which in turn may need to inform the Persistence service that it needs to save the player's inventory data, etc. The reason for choosing such a complicated architecture is that it scales very well - just add extra machines for extra services where needed
share|improve this answer
add comment

I would imagine that it is better to have one game server per "zone", of the game to avoid unnecessary complicated chit-chat between game servers.

I'd recommend that the clients connect directly to individual servers, and the master server just handles authentication and tells them which server to go to (depending on which zone they're in or other criteria).

In fact, having the master server as a "proxy" is probably a bad idea. Using a proxy is only helpful if you want the choice of destination server to be transparent to the client, or hidden from it.

If your game client is a custom client, this is not necessary, it can connect to whichever server you want.

share|improve this answer
add comment

Loadbalancing in that manner works best if the work performed in the backend is far more than the work to reroute the messages, if the clients messages are along the line of "Moving Right"/"Jumped"/"Fired", then this method will be spending a lot of time routing messages that basically only result in a flag being changed on the backend server.

Instead of hiding the gameserver behind the loadbalancer you can instead send a message to the game client to connect to a specific IP:port. By giving it a random one-time key that it then gives to the second server in a handshake sequence you can securely and quickly route players to different servers.

Should you need to rebalance you can have the loadbalancer request gameserver A to pass X number of clients to the gameserver B, the servers then perform a handshake to transfer any necessary information, and then the client is sent a new key and IP:port to connect to. This last part may not be possible during an ongoing game, but that depends on the nature of the game, in a MMO you would send players from one server to another as they reach certain transition areas for instance.

share|improve this answer
    
thanks for the answer; i thought of your model earlier, but due to security concerns i didnt want to let the client directly connect/communicate with sub servers, if you think it'd be a better model i'll consider it; one of the reasons i didnt pick your model was "seamless" issues. if i had a master-server-client architecture i can just redirect messages from one to another rather than connecting again, anyways; i do have some other questions. Will having a proxy architecture like i mentioned be a deal breaker and how big will it affect the latency compared to your model? –  Van Holtz May 4 '12 at 2:09
    
one more thing, do you know how the big game companies handling their game servers? like MMO servers(WoW, Rift, Lotro, etc) I'm just curious so I can do more R&D on them? thnx again! –  Van Holtz May 4 '12 at 2:09
    
As I mentioned, it depends on your game. The latency added is the time required to identify where to route the message, leveraging hardware solutions like port forwarding or other options should be the fastest way of doing it, but if its a turnbased strategy game where each message is a list of commands performed during your turn, it would be overkill since the time taken to process the message could measure in seconds rather than milliseconds. The best option is to measure the time it takes, both for the message itself and the forwarding of it. –  Daniel Carlsson May 18 '12 at 10:48
    
As for the big MMOs, no I cant say I got any inside knowledge for these. Older ones like EQ tend to be obvious since you receive a loadingscreen going from one zone to another, which is partially the client loading new data, but also the game server being split to different machines for loadbalancing purposes. Newer MMOs without zoning does the same thing of course, just with less obvious changeover points and without needing to effectively pause the game for the player during the switch. –  Daniel Carlsson May 18 '12 at 10:51
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.