Application Version Configuration
Last updated
Was this helpful?
Last updated
Was this helpful?
In this section, we will cover how to properly set up your application to efficiently use sessions. We will show you how to use the finer settings to tailor usage to your specific needs. We won't cover the basic application version configurations here, but you can refer to this to learn more about them.
All configuration related to sessions can be found under the session_config key when .
Session Kind
As mentioned earlier, one of the first things you will need to do is choose the type of session, either Match or Seat. A quick recap would be that you need to use Seat if you want each player to have their own socket, and use Match if you want each session to have a shared socket for all players.
There is a third option called Default, which means that the session feature is not used. This is the default option for application versions created without specifying a session kind.
Session Sockets
The session sockets parameter determines the maximum number of players or matches, depending on the session type, that can be hosted on your deployment at any given time.
If you use Seat, the number of session sockets will mostly depend on how many simultaneous players you want to host in a single instance of your server. If you use Match, it will depend more on the optimization of your server code. Generally, the fewer resources each instance consumes, the more session sockets you can fit into a single deployment.
Autodeploy
Unless you want to fully manage your deployment on your own backend, this option is recommended to ensure that your sessions don't fail. It guarantees that you will always have a deployment available on demand to host your sessions whenever needed.
The autodeploy option is a simpler version of a , where the system automatically creates deployments based on the demand of your application, without any minimum or maximum restrictions. It can be useful for applications that have a highly variable demand and need to scale up and down quickly without any constraints.
Empty Time to Live
This option determines how long a deployment without any active sessions should be kept before being automatically deleted. We recommend setting a value to avoid the cost of running unused deployments for too long.
This is especially important if you're using the autodeploy option, as it could result in a buildup of unused resources if not managed properly. This option enables fully automated scale down of game servers.
To ensure proper functioning of this feature, it is imperative that you delete your `Seat` or `Match` session when they are no longer needed. Otherwise, we will not be able to perform the scale down. Please note that we do not determine that a deployment is empty when there are no more connections, but when there are no more sessions associated with the deployment.
Session Deletion Delay
If you need to delete a deployment and there are still sessions on it, the sessions won't be immediately deleted. You can set how much time after the termination of the deployment your sessions should be deleted. This allows you to perform any necessary manipulation on the sessions before they are deleted. By default, the deletion time is set to 60 minutes, and you cannot set it to a value lower than that.
The name of this variable is session_max_duration in both the API and dashboard, although we acknowledge that the name can be confusing.
If you delete a deployment before disconnecting your players and terminating the sessions, it will disconnect the players from the server, as the server will no longer be available. This is not recommended.