Skip to main content

More In Depth

What are sessions?#

The behaviour described in the last few pages might be more suitable for some use cases. Since it implies some differences in the management of the server, we feel it is necessary to identify precisely how the deployments will behave.

That is why we added the option to create a session-based app version.

Let's break down the basic concepts:

  • A session-based app version will have a given number of sockets or session slots.
  • A session has a size and a user count. It is essential to understand the difference between these two to use the sessions properly:
    • The session size represents the number of sockets that this session uses on the deployment.
    • The user count is the number of players associated with the session and is determined automatically with the given player data when creating the session.

Session Kinds#

When creating an app version, you will have to choose a session kind. Your choice heavily impacts the management of your servers (in a good way, we swear) and has the potential to save you a lot of trouble. Here are the different session kinds and the basic idea.

KindType of app versionDescription
DefaultNormalEvery time a game is requested, it creates a new deployment. We terminate it when you ask for it (e.g., all players have quit or the game is over). This is not use with sessions.
SeatSession-BasedThere are many available sockets on every active deployment. When you ask for a session with a player, we assign it to a socket. When you delete the session, we free the socket (e.g., the player leaves the game).
MatchSession-BasedYou can find many available sockets on every active deployment. When you ask for a match, it is assigned to one socket, regardless of the number of players. When you delete the session, we free the socket (e.g., when the match is over or every player has quit).

What do you mean, "type of app version"?#

We use this term to describe the behaviour of the deployments of the app version.

A deployment is created on the fly for a Normal app version every time you want a game instance and deleted when you ask for it.

With a Session-Based app version, the deployments have limited available sockets, which are gradually assigned and freed with sessions. This way, you can allow multiple matches on a single deployment or let users jump in freely and out of the deployed app version.

Let's see concrete use cases to clarify things:#


You have developed an app to host online trivia tournaments, which requires optimal latency for fairness, and you need to start the app on-demand. You would create an app version of type Default.

When you have the players' info and are ready to start the match, you request a deployment with the users' info and have the match up and running within seconds.


Say your game pits two teams of three players in a 3v3 deathmatch, and you want to be able to host ten matches on every deployment. You would then create a session-based app version of type match with ten sockets.

When a group of six players are ready to play, you would then create a session with the IP addresses of the players. This process would create a session of size one and a user count of 6. This session would then link to a deployment, and the deployment could still receive nine more games like this.


In the case of an MMORPG, you would probably define the maximum load on the server by player count. In this case, you would create a session-based app version of type Seat with a set number of sockets equal to the maximum number of players the server can handle.

Whenever a player wants to log in, you would create a session with the player(s) info, and every player so made would take up one socket of the deployment. A player logging in to play solo would take up one socket, but if you wish to connect a party of 4 to the same deployment, it will take up four sockets.


The capacity of a session#

Session-based application versions have a capacity attribute named session sockets. When you link a session to a deployment of this app version, the session reserves several sockets on this deployment. When the session disconnects from the deployment, the sockets are freed, and another session can take its place.

Session socket management is usually pretty straightforward, but be aware that in the case of seat-based application versions, you might connect a session of more than one player (a party of 4, for example), which would take up four sockets in the deployment. Since the sockets are only freed when the session ends, if one of the players leaves, his socket would still be reserved in the deployment.

As of right now, you cannot disconnect one member of a group within a session. You can, however, create multiple sessions of one player and specify the same deployment. Disconnecting a player from a group is an upcoming feature.

Session's parameters#

Empty time to live#

The number of minutes a deployment of this app version can spend with no session connected before being terminated.


A deployment is made autonomously if there are not enough sockets open on a new session. Activating this option will automatically create new deployments if your deployment becomes crowded with sessions.

Session Max duration#

The lapse of time after you terminate a session-type deployment to remove all the session information connected to your deployment from the Sessions menu in the dashboard. The minimum and default values are 60 minutes, so you can manage your session termination before the session gets removed.