Application Version Configuration

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 part of the documentation to learn more about them.

If you're still unsure about which product best suits your needs, don't hesitate to join our Discord for assistance. However, if you've made it this far, you're likely confident that you need to use sessions in your application.

Best Practices for Configuring Sessions in Your Application Version

All configuration related to sessions can be found under the session_config key when creating an application version.

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.

When using Seat sessions, each player is represented by an IP address that you send to us in the session request. It is important to include the IP address, as it allows us to accurately track socket usage for each deployment. Without it, you may not be able to see the socket usage information you need.

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 fleet, 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.

You probably will not need to set this value unless you have specific needs. In most cases, it is recommended to leave it at the default value.