Gérer la requête

Dans cette section, nous montrerons un exemple basique sur la façon dont vous pouvez gérer une requête de session du début à la fin.

Disons que nous avons un ensemble de versions d'application avec Seat, quatre sockets, et autodeploy. Vous devriez revenir à la documentation de la session si vous n'êtes pas familier avec ces termes.

Créer la requête initiale

Notre matchmaker a déterminé que des joueurs avec les adresses IP 1.2.3.4 et 5.6.7.8 veulent jouer ensemble. Le matchmaker enverra une requête pour créer une session pour eux. Vous pouvez trouver la documentation API complète ici.

Nous n'avons actuellement aucun déploiement pour héberger notre requête de session, donc Arbitrium en créera automatiquement un pour nos deux joueurs.

Il n'est pas idéal d'interroger l'API à plusieurs reprises pour vérifier si la session est prête. Pour éviter cela, vous pouvez utiliser un webhook, ce qui est la pratique recommandée.

POST - /v1/session

{
  "app_name": "demo",
  "version_name": "v1",
  "ip_list": ["1.2.3.4", "5.6.7.8"],
  "continent": "Amérique du Nord",
  "webhook_url": "https://my-webhook.com/callback"
}

Gestion des statuts de session

Vous recevrez le même corps que vous choisissiez d'utiliser le webhook ou de faire des GET requêtes. Le GET corps de la session contient divers statuts et clés, mais vous n'avez besoin de gérer que la clé status. Les trois statuts que vous devez gérer sont Prêt, Erreur, et Intraitable.

Erreur et Intraitable

Si votre session est dans l'un de ces deux statuts, cela signifie que nous n'avons pas pu lier votre session à un déploiement prêt. En conséquence, vous n'aurez pas d'URL pour connecter vos joueurs. Il est important que vous gériez ces statuts dans votre backend. Cela peut arriver pour diverses raisons.

• Vous n'avez pas activé l'option autodeploy donc aucun déploiement n'est disponible ou ils sont tous à pleine capacité.

• Nous n'avons pas pu déployer votre version d'application en raison d'une mauvaise configuration.

Prêt

Lorsque le statut de votre session est Prêt, cela signifie qu'elle est prête pour que vos joueurs se connectent au déploiement. Vous pouvez prendre l'URL de connexion dans la partie ports du déploiement du GET corps.

GET - /v1/session/{session_id}

{
  "session_id": "bc4d21eaf686-S",
  "status": "Ready",
  "deployment": {
    "request_id": "628572d11014",
    "fqdn": "628572d11014.st.edgegap.net",
    "ports": {
      "80": {
        "link": "628572d11014.st.edgegap.net:32072"
      }
    }
  }
}

Il y a plus d'informations dans le corps, mais nous avons supprimé ce qui n'est pas lié à l'exemple pour plus de clarté.

Initialisation, Recherche, Attente

Ce sont des statuts en attente, ce qui signifie qu'ils surviennent lorsque nous analysons actuellement quel déploiement devrait héberger votre session ou lorsque nous déployons actuellement un nouveau déploiement. Vous n'avez pas vraiment besoin de gérer ces statuts.

Suppression d'une session

Lorsque vous déterminez que vous devez supprimer la session, que ce soit parce que vous déconnectez la connexion entre le serveur et vos joueurs et/ou que la partie est terminée, vous devez nous envoyer une requête de suppression.

Vous pouvez simplement supprimer une session avec un DELETE requête vers /v1/session/{SESSION_ID}. Votre session passera dans un état de Terminaison avant de ne plus être disponible.

Comme mentionné plus tôt, les sessions ne sont pas des connexions physiques, et par conséquent, vous devez gérer la connexion et la déconnexion physiques de vos joueurs. Ces manipulations doivent être synchronisées avec la création et la suppression des sessions. Si vous ne supprimez pas vos sessions, cela entraînera une fausse utilisation des sockets de session, et vous finirez par consommer beaucoup plus de ressources que nécessaire. Il est important de noter qu'Edgegap n'est pas en mesure de déterminer quand vos joueurs doivent être connectés au serveur ou non, vous devez donc gérer cela dans votre backend.

Filtrage de base

Vous pouvez filtrer les sessions pour imposer un emplacement spécifique tel qu'un pays, continent, ou ville. Vous pouvez également spécifier une latitude et longitude, et le déploiement sera effectué aussi près que possible de ce point géographique. Vous pouvez voir la liste complète des filtres ici. Cela peut être utile à utiliser dans votre système de matchmaking.

Dans la section suivante, nous vous montrerons comment vous pouvez faire un filtrage avancé en utilisant Sélecteurs et des tags sur vos déploiements.

Flux d'appels du webhook de session

Lorsque vous créez une session, vous pouvez fournir une URL de webhook pour recevoir des mises à jour sur le statut de la session. C'est une manière plus efficace de gérer vos sessions que de sonder l'API.

Le diagramme de séquence suivant illustre le flux d'appels d'un webhook de session.