The behavior described in the last few pages might be more suitable for some use cases, and since it implies some differences in the management of the server, we feel it is necessary to properly identify how the deployments will behave.
That is why we added the option to create what we call a session-based app version.
Let's break down the basic concepts:
- A session-based app version will have a number of sockets, or session slots. This is the number of sessions that can be connected to a deployment of this app version.
- 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 is 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.
When creating an app version, you will be asked to choose a session kind. This 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.
|Kind||Type of app version||Description|
|Default||Normal||Every time a game is requested, a new deployment is created. When you ask for it, we terminate it (e.g., all players have quit or the game is simply over).|
|Seat||Session-Based||There is a number of 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).|
|Match||Session-Based||There is a number of 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 are freeing the socket (e.g. When the match is over or every player has quit).|
We use this term to describe the behaviour of the deployments of the app version.
For a Normal app version, a deployment is created on the fly, every time you want a game instance and deleted when you ask for it.
With a Session-Based app versions, the deployments have a number of available sockets which are gradually assigned and freed with sessions. This allows to have multiple matches on a single deployment or to allow users to freely jump in and out of the deployed app version.
You have developed an app to host online trivia tournaments, which requires optimal latency for fairness, and need to be able to start the app on-demand. You would create a app version of type Default.
When you have the players' info and are ready to start the match, you would simply 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 10 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 would result in the creation of a session of size 1 and user count of 6. This session would then be linked to a deployment, and the deployment could still receive 9 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 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 created 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 4 sockets.
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 a number of sockets on this deployment. When the session is disconnected 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 1 player (a party of 4, for example), which would take up 4 sockets in the deployment. Since the sockets are only freed when the session is terminated, 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.