How It Fits Together: Difference between revisions

From OuroDev
← Older edit
VisualWikitext
Taffer (talk | contribs)
Mender
12 edits
m Try not to confuse people coming in from "Server Arch", and link to "Client Arch" for when that exists.
Asuffield (talk | contribs)
Mender
352 edits
 
(4 intermediate revisions by 2 users not shown)
Line 14: Line 14:
* [[chatserver]] - [[chatadmin]], [[chatclient]]
* [[chatserver]] - [[chatadmin]], [[chatclient]]
* [[cmdrelay]]
* [[cmdrelay]]
* [[dbserver]]
* [[dbserver]] - DB Server is the actual "shard" (and does surprisingly little database work).
* [[game]]
* [[game]] - Game Client
* [[launcher]] - Launch (and update) the game client.
* [[launcher]] - Launch the game servers.
* [[mapserver]]
* [[mapserver]]
* [[missionserver]]
* [[missionserver]]
Line 33: Line 33:
# Run Launcher. This is being replaced by things like [https://github.com/thunderspynetwork/creamsoda Cream Soda].
# Run Launcher. This is being replaced by things like [https://github.com/thunderspynetwork/creamsoda Cream Soda].
# Launcher runs Game Client.
# Launcher runs Game Client.
# Game Client connects to Auth Server, receives auth token of some sort.
# 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 DB Server, which is the actual "Shard".
# Game Client connects to dbserver, which is the actual "Shard".
 
# Game Client sends a [[Client-to-dbserver#DBGAMECLIENT_LOGIN|login]] message to dbserver, and receives a lot of data in return.
The Game Client also connects directly to ????TODO??? during play.
# Game Client shows player selection screen
# 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 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.


For more info about the Game Client, see [[Client Architecture]].
For more info about the Game Client, see [[Client Architecture]].


== Server's POV ==
== Server's POV ==
=== Player login ===
# 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-to-mapserver#DBSERVER_CONTAINERS|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 [[Dbserver-to-mapserver#DBCLIENT_CONTAINER_ACK|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 [[Client-to-dbserver#DBGAMESERVER_MAP_CONNECT|DBGAMESERVER_MAP_CONNECT]] to the game client. Otherwise this is a map transfer, so dbserver sends [[Dbserver-to-mapserver#DBSERVER_MAP_XFER_OK|DBSERVER_MAP_XFER_OK]] to the client's current MapServer, which forwards it to the client as [[Client-to-mapserver#SERVER_MAP_XFER|SERVER_MAP_XFER]].
# the game client connects to the new MapServer as directed


??? TODO ???
??? TODO ???
See [[Dbserver-protocols]] for info about how the DB Server talks to things.

Latest revision as of 15:45, 26 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:

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:

  1. Run Launcher. This is being replaced by things like Cream Soda.
  2. Launcher runs Game Client.
  3. Game Client connects to AuthServer, receives auth token of some sort. AuthServer sends the token and some related data to dbserver.
  4. Game Client connects to dbserver, which is the actual "Shard".
  5. Game Client sends a login message to dbserver, and receives a lot of data in return.
  6. Game Client shows player selection screen
  7. Game Client sends a choose player message to dbserver, which begins the process of loading the character onto a MapServer.
  8. 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.
  9. 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

Player login

  1. dbserver receives auth data from AuthServer with the client's login cookie
  2. game client connects to dbserver (as above), possibly via QueueServer
  3. dbserver authenticates the client, and notifies AuthServer that the client is connected
  4. dbserver requests an inventory from AccountServer, and sends it to the client
  5. dbserver loads the Entity containers owned by this player from the database, and sends them to the client
  6. game client sends a player selection to dbserver
  7. dbserver creates or loads the character as requested, and fetches everything needed from the database
  8. 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.

  1. 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
  2. if a new MapServer needs to be started, dbserver picks a suitable launcher and directs it to start a MapServer
  3. 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.
  4. MapServer asks dbserver for the containers for the groups that this Entity is a member of, and waits for a response
  5. MapServer notifies RaidServer and any other MapServers in the same teamup and league that the Entity is now on this map
  6. MapServer positions the Entity on the map, based on the door they loaded into
  7. MapServer generates a login cookie for the game client
  8. when this process is complete, MapServer sends DBCLIENT_CONTAINER_ACK to dbserver with the login cookie
  9. 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.
  10. the game client connects to the new MapServer as directed


??? TODO ???

See Dbserver-protocols for info about how the DB Server talks to things.

Retrieved from "https://wiki.ourodev.com/index.php?title=How_It_Fits_Together&oldid=1176"