Server Queue

Server Queue Flow

When joining a server, players will be entered into a queue that allows players to join gracefully and securely. This helps prevent any overloading of servers, allows us to accurately predict and scale servers as needed, and ensures that all players fairly get access to servers.

An average wait time will be displayed when players initialise joining, and for most servers, this will be less than 60 seconds.

Technical Specs

To ensure the queue is joined successfully, it’s important than the following flow is adhered to in your implementation:

  1. Issue join server as player clicks “join”:
    1. If the server has a password, you will need to send this in the POST payload. This can be determined from the server listing endpoint’s has_password response.
  2. This will either return a queue token that is valid for ~6 minutes, such as 00000000-0000-0000-0000-000000000000, or error if the password is incorrect, or other invalid states such as missing consent
    1. If the password is incorrect, take user back to the server listing page, and inform them of the error.
    2. Refer to documentation on Player Consents for any consent-related errors.
  3. Otherwise, use this token to get information on the queue:
    1. This will return information about the queue size, estimated wait time, and a sessiono.
    2. Start rendering queue UI with this information, giving the player a clear indication of how long the estimated wait time is.
  4. Every 10-15 seconds, long-poll for the queue via the same endpoint
    1. If the date_expires is within 1 minute, issue a renew server queue:
    2. This will give you a new token, with a fresh 6 minutes expiration date, which you should then return to step 2a for
  5. At some point, the queue token will return a session, and this value with change from null, to an object that includes a token, date_expires, and server_connection.
    1. This object can then be passed to the game to initiate the connection to the game server.