Sign in to follow this  
beebs1

Server Communication

Recommended Posts

Hiya,

My university dissertation involves building authentication and simple game mechanics for a large-scale online game. I'm a little stuck with how processes in a game server cluster should communicate, and I was hoping someone could help :)

Currently I have a login process, which is connected to an accounts database. Players initially connect to this using TCP and authenticate their account. I also have a number of world processes, each connected to their own game world database.

After authenticating, the login process needs to send the player a list of in-game characters available - so the login process should be aware of what world processes are available at the time. I also need to handle new world processes starting, and processes either halting or crashing.

The only way I can think of doing this is to use UDP broadcasts on the servers' private network. When a process comes online, it broadcasts a small packet saying "Hi, I'm a login/world/whatever server!" to everyone else in the cluster. It can also broadcast if it goes offline or hits an unhandled exception. Other processes can then reply with their own UDP message (not a broadcast) if necessary. For example, when a world process receives a broadcast of a new login process, it should send it's own 'Hello' message back. The login process therefore knows the world is available and can offer it to players who have a character there.

It seems reasonable to me, but I was hoping to hear what others think. Maybe there are other ways I should consider?

Many thanks :)

Share this post


Link to post
Share on other sites
This seems fragile to me. If you crash or are terminated, you can't send a "I'm down" message to the broadcast, so failing servers won't be caught correctly.

A more typical approach is to have a centralized authority server that acts as a registry of every available game server. When a game server starts, it opens a persistent TCP connection to the point of authority, and periodically sends keep-alive messages to that program/machine. You can tune the time between these messages, but 30 seconds is a good start. If the authority notices that the TCP connection is closed or hasn't checked in for a while, it marks the server dead and stops forwarding requests to it.


Of course, the details depend a lot on how decentralized your game logic servers are, and how all that works.

Share this post


Link to post
Share on other sites
Thanks very much. That does sound like a better approach.

What do you think about the central server failing? I could use reduntant authority servers, but that means each process needs a connection to each central server, and complicates things.

Or would this be something solved at a higher level, using failover or the like?

Thanks again.

Share this post


Link to post
Share on other sites
[quote name='beebs1' timestamp='1318349802' post='4871487']
Hiya,
...

After authenticating, the login process needs to send the player a list of in-game characters available - so the login process should be aware of what world processes are available at the time. I also need to handle new world processes starting, and processes either halting or crashing.

The only way I can think of doing this is to use UDP broadcasts on the servers' private network. When a process comes online, it broadcasts a small packet saying "Hi, I'm a login/world/whatever server!" to everyone else in the cluster. It can also broadcast if it goes offline or hits an unhandled exception. Other processes can then reply with their own UDP message (not a broadcast) if necessary. For example, when a world process receives a broadcast of a new login process, it should send it's own 'Hello' message back. The login process therefore knows the world is available and can offer it to players who have a character there.

It seems reasonable to me, but I was hoping to hear what others think. Maybe there are other ways I should consider?

Many thanks :)
[/quote]

You might also have the avaliable 'process' broadcasts have a timeout on the receiver end and have the broadcast be made regularly (ie- a variant of a 'keep alive' signal)
so that if the process aborts before it can signal that it is shutting down (or something like the network channel dies) the other end can assume it is dead and act accordingly.

Complete failures thus could be detected/handled and then all the other flavors of 'soft' failures could be done with status messages (and be handled according to their types)


Oh and that also takes care of the case where the receivers side starts up and any resource processes would already have sent their startup announcements (once).

And since you say UDP there is ALWAYS the possibility that packets get lost and by sending them constantly (like once a second or few seconds)
then it will handle the lost packet case (as long as your failure timeout is many send cycles long as it normally should be anyway)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this