How It Fits Together

Server Architecture

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:

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

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.