Sign in to follow this  
39ster

Quick question regarding multiple zone servers

Recommended Posts

If the player needs to connect to a new server (when he goes into a new zone) the players properties/items needs to transfer over to the next zone server. Just wondering what's the best way to do this? Just have the previous zone server save the players properties to MYSQL then have the next zone server load them from mysql?

Share this post


Link to post
Share on other sites
Typically, you'd have some kind of backend database to which the player's items/stats are synchronised every now and then (at least when they log off - probably more often). When they transfer between servers, just do the synch before they transfer.

Share this post


Link to post
Share on other sites
Ok another question regarding Authentication server and Zone server. Just wondering if this is the correct way to do it, and if not, what is the best/correct way to do it?

-Player logs into Authentication server (send user/pass stuff)
-Authentication server creates a session ID and sets a field in the database to this session ID (like a primary key for the players properties).
-Authentication server sends the session ID to the player.
-Player connects to the zone server and sends the session ID to zone server.
-Zone server uses this session ID to verify the player and locate their properties.

Share this post


Link to post
Share on other sites
Certainly that's one way to do it. I would also include the IP address of the client in the database table so that another client would not be able to pass the same session-ID and "steal" the connection...

Share this post


Link to post
Share on other sites
Depends on how exactly the cluster is designed, and how data is persisted. Writing and reading same data is likely to be too expensive and probably not required.

If you have external database, and all zone servers have access to it, then it depends only on how often you store data.

One way is would be similar to this (A and B are zone servers):
- Client requests to move to new zone
- A stops processing client related input and stores
- Server initiates database commit
- A sends sends all client-related data + queue to B
- A tells client to connect to B
- A now waits until database commit reports success, and B reports success
- Once successfully connected, client and B signal A transfer completed
X B starts processing pending client's messages
- Client closes connection to A
- A now disposes client-related data

If process fails at any point before X, you abort the transfer. If something fails at X or after X, then client might be disconnected, but state should remain consistent.

There is still the problem of how to update the client during this transfer. If transfer takes some time, then other players may see that avatar just standing at zone border, not responding.


Another way, if your zones share borders and character data is shadowed across them, the process of serialization is simpler, since both servers already know all data.

- A stops processing B
- A passes B all pending messages
- A tells B to assume command
- A tells client to connect to B
- Once client confirms connection, and B reports success, you're done

Note that there is no clean-up here, since A will now be shadow copy.

There is no need for explicit database commit. Since each zone server (according to some rules) stores the changes, and since both servers have same data already, changes will be committed to DB as before.

One detail about this however is, objects being transferred might still be targets of events on A. So during transfer process, you need to keep forwarding these messages to B without processing them. This effectively looks as if client lags for a short time, and once B catches up, all these events are processed at once.

As far as database commit goes, you should always have some way to track if such commit is needed. If you always commit full state, then a bunch of players will get together and jump across the zone border and crash or at least lag the servers. Simply put - commit what and when it needs to be commited.

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