Client-to-dbserver

The game client connects to port 7000 to find dbserver, and uses the common Network protocol.

When a QueueServer is in use, then it listens on port 7000 and clients will connect there. Otherwise, dbserver listens on port 7000 and accepts client connections.

dbserver game client interface

When a game client disconnects from dbserver, then:

• if the client is not logged in, dbserver sends AS_QUIT_GAME to authserver with reason 1
• if the client is logged in but does not have an entity loaded, dbserver sends AS_QUIT_GAME to authserver with reason 2
• if the client is loaded onto a MapServer, then the MapServer is sent DBSERVER_FORCE_LOGOUT with reason -1
• if the client is loaded but not connected to a MapServer, then an ACCOUNT_CLIENT_LOGOUT_ACCOUNT is sent to AccountServer and AS_QUIT_GAME is sent to authserver with reason 3

When dbserver receives a command on a link from a client, it first checks if the server is shutting down, and if it is then sends the client DBGAMESERVER_MSG with "ServerShutdown", and quits the client.

When quitting a client:

• If QueueServer is not used, dbserver closes the link
• If QueueServer is used, dbserver sends QUEUESERVER_SVR_REMOVECLIENT to QueueServer for this client

If the client is not logged in, then receiving any message other than DBGAMECLIENT_LOGIN will result in DBGAMESERVER_MSG with "NotLogged", and quits the client.

When QueueServer is used, the protocol is modified by prefixing headers onto packets so that QueueServer can proxy them. See Dbserver-protocols#queue for details.

Commands, client to server

DBGAMECLIENT_LOGIN

Header if QueueServer is in use:

autobits client_ip
autobits client_link_id

Body of request:

string account_name
packint(1) auth_id
packint(1) protocol_version
bits(64) test_auth_data
packint(1) dont_check_version
string game_version
bits(64) game_checksum
bits(32) cookie
optional bits(1) no_timeout
optional string patch_value
optional string not_used
optional zipped system_specs
optional packint(1) keyed_access_level
optional string issued_to

If login fails, and QueueServer is not used, the message is ignored.

If login fails, and QueueServer is used, then a QUEUESERVER_SVR_REMOVECLIENT will be sent to QueueServer and the game client destroyed. (Bug: the pointers are not cleaned up so if more messages come back from QueueServer then dbserver will break)

protocol_version must be DBSERVER_CLIENT_PROTOCOL_VERSION (20110614) or dbserver will send DBGAMESERVER_MSG with "WrongProtocol" and fail login.

test_auth_data is used only if fake auth is enabled, and will be used as the auth user data which AuthServer would have set.

If fake auth is not used, and the correct game client version number begins with "dev:", then version checking is disabled. If dont_check_version is 0 in the request, version checking is disabled. Otherwise, the game_version field is checked for case-insensitive equality with the correct client version recorded in dbserver. If it does not match, dbserver will send DBGAMESERVER_MSG with "WrongVersion %s %s" or "WrongVersionPatcher %s %s" and fail login.

If version checking was disabled by the request from the client, then dbserver will instead attempt to match the "Branch" field of the versions. If both versions have a branch and they don't match, dbserver will send DBGAMESERVER_MSG and fail login.

account_name is stored in the GameClientLink struct with the value sent by the client.

If fake auth is not used, dbserver now checks for a valid auth entry from AuthServer. cookie is used to look up an auth entry, which must match cookie and account_name in order to be used. If it does match, then the following pieces of data are copied from the AuthServer data to the GameClientLink:

• account name
• loyalty
• loyaltyLegacy
• payStat
• auth user data

vip is then set based on payStat, and vipFlagReady is set to 1.

The auth entry is cleared if a match is made. If a match is not made, dbserver will send DBGAMESERVER_MSG with "DBInvalidLogin" and fail login.

If fake auth is used, then test_auth_data is used from the client, the loyalty points are set based on servers.cfg settings, and vip and vipFlagReady are both set to 0. A fake auth_id is generated.

At this point the client is marked as successfully logged in, and AS_PLAY_GAME is sent to AuthServer.

If no_timeout is not 0 and dbserver is not in production mode, then the client link has timeouts disabled.

patch_value is ignored.

system_specs is logged but otherwise ignored.

keyed_access_level and issued_to are ignored, but issued_to is only present if keyed_access_level is not 0.

If the authname limiter is set in servers.cfg, then the account name is now checked against the names in server/db/auto_allowed_authnames.cfg and server/db/allowed_authnames.cfg. If the limiter is set and the account name is not in the allowed lists, and the auth limiter is configured in servers.cfg to enqueue, then the client is set to be queued. Otherwise, dbserver will send DBGAMESERVER_MSG with "AccountNotAllowed" and fail login. (Bug: this has happened after the client is marked as logged in, so they are rejected but still able to send other commands.)

If queue server is used, the queue is now checked to see if players should be allowed to connect, taking the first match in this list:

• People in the auto-login list, or reconnecting players, will be allowed
• Free players are queued if AccountServer is not responding
• Everybody is queued if overload protection is enabled
• If nobody is queued, and MaxPlayers is set in servers.cfg, and the number of online people is less than MaxPlayers, the player is allowed
• If the auth limited is in queueing mode, and the player is allowed to login, and the number of online people is less than MaxPlayers, the player is allowed
• Otherwise they are queued

QUEUESERVER_SVR_ENQUEUESTATUS is then send to QueueServer with the decision made.

If queue server is not used, the player is directly logged in (this procedure will be invoked by QueueServer in QUEUECLIENT_CLIENTPLAY):

• The ShardAccount for this auth_id is marked as logged_in
• DBGAMESERVER_ACCOUNTSERVER_CATALOG is sent to the client
• ACCOUNT_CLIENT_REGISTER_ACCOUNT is sent to AccountServer
• ACCOUNT_CLIENT_AUTH_UPDATE is sent to AccountServer
• ACCOUNT_CLIENT_INVENTORY_REQUEST is sent to AccountServer
• DBGAMESERVER_ACCOUNTSERVER_INVENTORY is sent to the client
• DBGAMESERVER_SEND_PLAYERS is sent to the client

DBGAMECLIENT_ACCOUNTSERVER_UNSECURE_CMD

This command is ignored.

DBCLIENT_ACCOUNTSERVER_CMD

In production mode, this command is ignored.

In development mode, this message is proxied to AccountServer as ACCOUNT_CLIENT_SLASHCMD:

autobits message_dbid
autobits auth_id
autobits dbid
string cmd