How It Fits Together
An attempt to explain the purpose of each part, and how they all fit together.
Based on the source directories, it seems like a full CoX system (that is, all servers, and the game client) is made up of these items:
- chatserver - chatadmin, chatclient
- dbserver - DB Server is the actual "shard" (and does surprisingly little database work).
- game - Game Client
- launcher - Launch the game servers.
Note: I'm probably slightly off, and will update this as I investigate further. Feel free to correct any lies in here!
From the player's point of view:
- Run Launcher. This is being replaced by things like Cream Soda.
- Launcher runs Game Client.
- Game Client connects to AuthServer, receives auth token of some sort. AuthServer sends the token and some related data to dbserver.
- Game Client connects to dbserver, which is the actual "Shard".
- Game Client sends a login message to dbserver, and receives a lot of data in return.
- Game Client shows player selection screen
- Game Client sends a choose player message to dbserver, which begins the process of loading the character onto a MapServer.
- When MapServer has finished loading the character, dbserver sends a map connect message to game client. This contains an IP address, udp port, and login cookie for the client to connect to the MapServer.
- Game Client directly connects to MapServer, as instructed. Most communication will be with the MapServer from now on, until the next time the player changes maps and needs to do a map transfer.
For more info about the Game Client, see Client Architecture.
- dbserver receives auth data from AuthServer with the client's login cookie
- game client connects to dbserver (as above), possibly via QueueServer
- dbserver authenticates the client, and notifies AuthServer that the client is connected
- dbserver requests an inventory from AccountServer, and sends it to the client
- dbserver loads the Entity containers owned by this player from the database, and sends them to the client
- game client sends a player selection to dbserver
- dbserver creates or loads the character as requested, and fetches everything needed from the database
- dbserver begins the process of loading the Entity onto the MapServer
Map loading and transfer
Whether from login or map transfer, the process of loading an Entity onto a MapServer is roughly the same.
- dbserver looks for a suitable MapServer for the requested destination. If this is a static (world) map, then it finds a suitable instance; if it is an instanced (mission) map, then it may have to create a new one
- if a new MapServer needs to be started, dbserver picks a suitable launcher and directs it to start a MapServer
- when a MapServer is ready, dbserver sends it a DBSERVER_CONTAINERS message with the Entity. This entity is locked to the MapServer, which now owns it until they leave the map.
- MapServer asks dbserver for the containers for the groups that this Entity is a member of, and waits for a response
- MapServer notifies RaidServer and any other MapServers in the same teamup and league that the Entity is now on this map
- MapServer positions the Entity on the map, based on the door they loaded into
- MapServer generates a login cookie for the game client
- when this process is complete, MapServer sends DBCLIENT_CONTAINER_ACK to dbserver with the login cookie
- dbserver directs the game client to connect to the new MapServer. If this is part of a login flow, then dbserver directly sends DBGAMESERVER_MAP_CONNECT to the game client. Otherwise this is a map transfer, so dbserver sends DBSERVER_MAP_XFER_OK to the client's current MapServer, which forwards it to the client as SERVER_MAP_XFER.
- the game client connects to the new MapServer as directed
??? TODO ???
See Dbserver-protocols for info about how the DB Server talks to things.