How It Fits Together: Difference between revisions
From OuroDev
| Line 35: | Line 35: | ||
# 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 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 connects to dbserver, which is the actual "Shard". | ||
# Game Client sends [[Client-to-dbserver#DBGAMECLIENT_LOGIN|login]] message to dbserver, and receives a lot of data in return. | # Game Client sends a [[Client-to-dbserver#DBGAMECLIENT_LOGIN|login]] message to dbserver, and receives a lot of data in return. | ||
# Game Client shows player selection screen | # Game Client shows player selection screen | ||
# Game Client sends [[Client-to-dbserver#DBGAMECLIENT_CHOOSE_PLAYER|choose player]] message to dbserver, which begins the process of loading the character onto a MapServer. | # Game Client sends a [[Client-to-dbserver#DBGAMECLIENT_CHOOSE_PLAYER|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 [[Client-to-dbserver#DBGAMESERVER_MAP_CONNECT | # When MapServer has finished loading the character, dbserver sends a [[Client-to-dbserver#DBGAMESERVER_MAP_CONNECT|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. | # 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]]. | For more info about the Game Client, see [[Client Architecture]]. | ||
Revision as of 15:35, 23 May 2019
Server Architecture
An attempt to explain the purpose of each part, and how they all fit together.
Components
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:
- accountserver
- arenaserver
- auctionserver
- authserver
- chatserver - chatadmin, chatclient
- cmdrelay
- dbserver - DB Server is the actual "shard" (and does surprisingly little database work).
- game - Game Client
- launcher - Launch (and update) the game client.
- mapserver
- missionserver
- queueserver
- raidserver
- statserver
- turnstileserver
Note: I'm probably slightly off, and will update this as I investigate further. Feel free to correct any lies in here!
Player's POV
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.
Server's POV
??? TODO ???
See Dbserver-protocols for info about how the DB Server talks to things.