Session
Last updated
Was this helpful?
Last updated
Was this helpful?
Sessions serve as a layer within the deployment and are used when you need to manage sockets or available space within a deployment. We will discuss the details later, but here are the typical use cases where sessions complement deployments:
Managing hop-in, hop-out of players or groups of players within a deployment.
Creating multiple matches or games within a single deployment.
A session cannot exist without a deployment, as a session is always associated with a deployment.
If you're in this section, it's likely because the regular flow of deployment doesn't perfectly suit your needs. Let's quickly recap the typical flow of deployments.
You provide us with a list of IP addresses, and we create a deployment with your application at the optimal location. Your users then connect to it. Once the game is over, you make another API request, and we will delete the deployment.
When you request termination of a deployment, we delete your game instance, making it no longer accessible to your players. If you need a new instance of your application for four other players, you can submit another deployment request.
However, if you're building an MMO or an open-world game, you may need to manage player entry and exit from an instance of your application. In such cases, your deployment is more likely to start empty, for example when you open a new server in a new region.
And the deployment can be populated over time as players enter and exit the instance. Alternatively, you can also apply the concept of player hop-in and hop-out for entire matches as well.
Sessions are a recommended approach over deployments alone when you require a more persistent game instance with players coming in and out or need to manage multiple games/matches per server instance.
Sessions are designed to simplify the development process by providing built-in functionality for managing players, matches, and game instances. However, it's worth noting that it is also possible to manage a "session-type" system in your backend using deployments without sessions if needed. Sessions are specifically designed to facilitate the use cases described above.
In the next section, we will delve into the concept of sessions in more detail.
Now that we've determined that sessions may be what you need, let's understand how they are used in conjunction with deployments more in details. We will use the same diagrams while adding one principle at a time.
In this scenario, we will assume that there is already a deployment available to host the session. In another section, we will explore how to automate the process of creating a deployment automatically when there is no existing deployment to host the desired session.
When a player intends to join a game instance, you create a session request to Arbitrium, either through your matchmaker or directly from the game client, depending on your game's implementation.
Sessions allow for adding multiple players to a single deployment by including their IP addresses in the same session request.
If you wish to remove a player from the deployment, you simply need to send a request to delete the session corresponding to that player.
And now, a new player can take the vacant spot by sending a new session request.
Now that you have a better understanding of a session, we will look at how they work and some specifics.
You can further manage players and sessions by adding or removing players from a specific session. .
