   Passing the ball: Moving between zones
  My game consists of collection of sectors of space where players fly around, collect resources, battle enemies, etc. Overview of the architecture:Real-time game play (the stuff that happens in a sector) is handled by a java app that can serve multiple sectors. There is no direct communication between sectors. When a sector starts, its initial state is read from a (mysql) database. When a player joins, their state is read from the database before being added to the sector. When something happens that requires persistence, the gameserver passes a message to datastore that effectively says "save this when you can."  The idea here is that sectors should not be blocked by the database.When a player leaves a sector, the gameserver disconnects them and sends a message to the datastore noting that.The gateway server is a php webservice backed by the same database. This is where stuff that's "less real-time" happens, such as the initial login and sector selection. When a player says "I'd like to jump to this sector" the gateway sees if that's allowed, and if so updates the player's location in the database. Some common edge cases:1. User disconnects (accidentally or deliberately) while in sector without having departed "normally."2. User reconnects after an abnormal disconnect.3. User double-connects to the sector (could even happen accidentally, because the game is flash-browser based).Some less common, but possible edge cases:1. User double-connects to the sector before the first connection has completed authentication.2. User reconnects to a sector after a normal departure, but before the datastore has learned that he's gone.I'm not looking for specific solutions to each of these problems, but rather best practices "passing the ball" to and from the game server. Also, feel free to mention other common edge cases.   
  You may want to consider adding to your gateway server a client gateway. The users and sector processes connect to the client gateway. The gateway merely shuffles data. When a player leaves a sector, the sector process notifies the gateway, and the gateway begins directing the users traffic to the new sector server that the player is in.--Z   ;  Sounds like what most MMOs did in the late '90s. (EverQuest, etc)Some other common cases:- Same user ID connects to two different sector servers.- Sector server containing user's location is down when user logs in.- User logs into sector server where database doesn't say user is.- User closes windows when about to lose a fight.- Configuration data goes wrong, so gatekeeper thinks machine A is sector 1 and machine B is sector 2, but machine A thinks it's sector 2 and machine B thinks it's sector 1.- Upgrading software, game data or configuration without restarting servers/dropping players.- User in sector 1 wants to "whisper" a message to user in sector 2.You'll probably want to end up having your sector servers communicating with the gateway server (or the DB backing the gateway server) as well, to do things like verify that the user is really in the current sector, etc.One good way to solve "zoning" (changing sectors) is to simply drop a user if he is not in that sector. When a user gets a "drop," he re-connects to the gatekeeper, which reads the right sector out of the database, and tells the user where to connect. Repeat as needed.;  This is a good list, thanks. I think my current design deals with most of them pretty well:Quote:- Same user ID connects to two different sector servers.Sector servers are responsible for specific sectors, so if someone connects to a server that isn't hosting their sector, the server won't recognize them.Quote:- Sector server containing user's location is down when user logs in.That is a potential problem. It's a bit of a corner case because when a user leaves a sector (normally or not) their sector is set to 0 aka "hyperspace" until they connect to a new sector. But if a sector crashes with users in it, those users will be stuck there unless some other code looks for crashed sectors.Quote:- User logs into sector server where database doesn't say user is.I think this is the same as the first case because the sector server authenticates via the database.Quote:- User closes windows when about to lose a fight.My current plan is to have the player's ship remain in sector but try to leave on autopilot. If the player reconnects before the ship leaves, they can resume control.Quote:- Configuration data goes wrong, so gatekeeper thinks machine A is sector 1 and machine B is sector 2, but machine A thinks it's sector 2 and machine B thinks it's sector 1.I guess if this happens I'd try to fix the underlying cause of the configuration data problem.Quote:- Upgrading software, game data or configuration without restarting servers/dropping players.I'm okay with server down time for maintenance if I have a mechanism to notify players in advance.Quote:- User in sector 1 wants to "whisper" a message to user in sector 2.There is a mechanism in the architecture to pass "slow messages" to a sector via the database.  Quote:One good way to solve "zoning" (changing sectors) is to simply drop a user if he is not in that sector. When a user gets a "drop," he re-connects to the gatekeeper, which reads the right sector out of the database, and tells the user where to connect. Repeat as needed.That's pretty much the way I'm going, with the addition of a "hyperspace" area that's managed by the gateway. An advantage with a space based game is that it provides a convenient excuse for non-seemless zone transfers.   ;Quote:I guess if this happens I'd try to fix the underlying cause of the configuration data problem.The higher-level take-away from that corner case is that you need to have things that check whether configuration is OK or not, and alerts when it isn't. Tracking things like # users in each sector is important. Also, you could have a monitor that asks the database how many users it thinks should be in each sector, then asks each sector server how many users actually are there, and alert on discrepancies (with some tolerance for the issue of a player just switching sectors).Which goes to the even higher-level take-away that you need active monitoring and alerting :-);  I really can't wait to see a demo of your game ... it's so frighteningly similar to our project that it definitely sounds like we're working on the same game!As was already noted, I think the most obvious exploit you face is the user that can in many ways attempt to exploit the delay in saving data and the immediate db-based player restore when a player logs in.  I think you need to make sure that when a player logs in, any pending writes for a past session have been written before you recreate their session from the db.  Otherwise, you'll see players with a login tab at the ready anytime they are about to be killed to auto-revive them before the db finds out they died.;  Yeah, they do sound similar, but probably have huge differences underneath. I think Dark Orbit sounds like my game from the description, but isn't really. I'll post a demo here when it's ready, but as you know these things are long projects.I'm thinking to prevent quick reconnects the sector server will maintain a map of pending user writes. Users won't be able to reconnect to the server until their entry is cleared.   