Quick question regarding multiple zone servers

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.

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.

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...

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.

I wrote an article on authentication for games, it's in Game Programming Gems 7. A web page describing most of the same content is available online:
http://www.mindcontrol.org/~hplus/authentication.html.