Rubriques avancées sur les sessions multijoueurs - XBOX Game Development Documentation

Utilisez cette rubrique pour découvrir les concepts avancés des sessions multijoueurs. Cette rubrique couvre les points suivants :

Vue d’ensemble des sessions
Propriétés des membres
Fonctionnalités de session
Taille de session
États des utilisateurs de session
Visibilité et possibilité de jonction
Délais d’expiration des sessions
Plusieurs utilisateurs connectés sur une même console
Gestion du cycle de vie des processus
Nettoyage des sessions inactives
Arbitre de session

Vue d’ensemble des sessions

Une session dans Multiplayer Session Directory (MPSD) possède un nom de session et est identifiée comme une instance d’un modèle de session. Un modèle de session est un document JSON qui fournit les paramètres par défaut de la session. Le modèle de session fait partie d’une configuration de service dotée d’un identificateur de configuration de service (SCID), qui est un GUID. Le modèle de session se trouve dans Partner Center. Les configurations de service sont les ressources destinées aux développeurs, utilisées pour l’ingestion, la gestion et la stratégie de sécurité. Lorsqu’une session est accessible via MPSD, l’autorisation du principal est effectuée par rapport à la configuration de service, selon les stratégies d’accès définies par le développeur dans Partner Center. Des vérifications d’accès secondaires, comme la validation de l’appartenance à la session, sont effectuées au niveau de la session lorsque celle-ci est chargée, une fois l’accès à la configuration de service autorisé.

Les fonctionnalités définies via un modèle ne peuvent pas être modifiées par des écritures dans MPSD. Pour modifier les valeurs, vous devez créer et soumettre un nouveau modèle contenant les modifications nécessaires. Tous les éléments qui ne sont pas définis via un modèle peuvent être modifiés par des écritures dans MPSD.

Numéro de version de contrat

Cette rubrique suppose que votre modèle utilise la version de contrat 107, qui est la version utilisée par le MPSD actuel pour XBOX One (ou version ultérieure).

Référence de session

Chaque session MPSD est identifiée de manière unique par une référence de session, représentée dans l’API multijoueur par la structure XblMultiplayerSessionReference. La référence de session contient les valeurs de chaîne suivantes.

Identificateur de configuration de service (SCID)
Nom du modèle de session
Nom de la session

La référence de session correspond à l’URI d’identification des sessions, comme indiqué ci-dessous. Dans l’exemple de correspondance suivant, authority est sessiondirectory.xboxlive.com.

https://{authority}/serviceconfigs/{service-config-id}/sessiontemplates/{session-template-name}/sessions/{session-name}

Éléments d’une session

Chaque session contient des groupes d’éléments qui appliquent des règles de mutabilité et de sécurité. Elles varient selon l’élément de session, et s’accompagnent d’informations de gestion en lecture seule (métadonnées). Cette section décrit les groupes d’éléments de session inclus dans les fichiers JSON permettant de configurer votre session, ainsi que dans le fichier JSON du modèle que vous choisissez.

Si vous utilisez des wrappers personnalisés pour une implémentation HTTP/REST, votre session et votre modèle doivent définir des objets JSON qui reflètent précisément les fonctionnalités de l’implémentation.

Chaque groupe d’éléments contient deux objets internes.

Objets système : ces objets ont un schéma fixe appliqué et interprété par MPSD. Ils sont validés et fusionnés. Comme MPSD les définit et connaît leur signification, il peut agir en conséquence. Pour la définition complète de chacun des objets système, consultez les références des éléments préfixés par XblMultiplayerSession et des URI de Session Directory.
Objets personnalisés : ces objets sont facultatifs et n’ont pas de schéma. Ils servent à stocker des métadonnées liées à une partie multijoueur. Comme MPSD ne peut pas interpréter ces données, il ne les traite pas. Les données de jeu ou les informations enregistrées doivent être stockées dans Title-Managed Storage (TMS). Pour plus d’informations sur TMS, consultez Vue d’ensemble de Title Storage des services XBOX.

Voici un exemple d’objet JSON personnalisé.

    "custom": {
      "myField1": true,
      "myField2": "string",
      "myField3": 5.5,
      "myField4": { "myObject": null },
      "myField5": [ "my", "array" ]
    }

Constantes de session

Les constantes de session sont définies uniquement au moment de la création, par le créateur ou par le modèle de session. L’objet /constants/system permet de définir des constantes pour le système multijoueur tel qu’il est connu par MPSD. Le wrapper associé à cet objet est représenté par la structure XblMultiplayerSessionConstants. L’objet /constants/system peut définir un certain nombre d’éléments. Ils comprennent un objet capabilities, un objet metrics, un objet managedInitialization (version de contrat de modèle 104 ou 105) ou memberInitialization (version de contrat 107), un objet peerToPeerRequirements, un objet peerToHostRequirements et un objet measurementsServerAddresses.

Propriétés de session

Utilisez l’objet /properties/system pour définir les propriétés de session pour MPSD. Le wrapper associé à cet objet est la structure XblMultiplayerSessionProperties. Les propriétés de session peuvent être écrites à tout moment par les membres de la session. Des exemples de propriétés de session au format JSON sont joinRestriction, initializationSucceeded et l’objet matchmaking. Pour un exemple d’utilisation de ce groupe d’éléments, consultez Initialisation de la session cible et QoS.

Constantes des membres

Définissez les constantes des membres au moment de la jonction, pour chaque membre de la session. L’objet JSON est /members/{index}/constants/system. Le wrapper qui représente un membre de session est la structure XblMultiplayerSessionMember. Retour en haut de cette rubrique.

Propriétés des membres

Les propriétés des membres ne peuvent être écrites que par un membre de la session. Elles sont définies dans l’objet /members/{index}/properties/system et reflètent les éléments de la structure XblMultiplayerSessionMember. Voici un exemple.

    {
      // These flags control the member status and "activeTitle" and are mutually exclusive (it's an error to set both to true).
      // For each, false is the same as not present. The default status is "inactive"; that is, neither present.
      "ready": true,
      "active": false,

      // Base-64 blob, or not present. An empty string is the same as not present.
      "secureDeviceAddress": "ryY=",

      // During member initialization, if any members in the list fail, this member will also fail.
      // Can't be set on large sessions.
      "initializationGroup": [ 5 ],

      // List of the groups I'm in and the encounters I just had.
      // An encounter is a brief interaction with a group. When an encounter is reported, it counts as retroactively joining the group 30 seconds ago and just now leaving.
      // Group names use the session name validation rules (like case-insensitive).
      // On large sessions, groups are used to report who played with whom (rather than just session membership). Members
      // who are active in at least one group together at the same time are counted as playing together.
      // Empty lists are the same as no value specified.
      // The set of encounters is a point-in-time property, so it's immediately consumed and will never appear on a response.
      "groups": [ "team-buzz", "posse.99" ],
      "encounters": [ "CoffeeShop-757093D8-E41F-49D0-BB13-17A49B20C6B9" ],

      // Optional list of role preferences that the player has specified for role-based game modes.
      // All role names have to match across all members in the session. Role weights are
      // defined from 0-100.
      "RolePreference": { "medic": 75, "sniper": 25, "assault": 50, "support": 100 },

      // Quality of Service (QoS) measurements by lowercase device token.
      // Like all fields, "measurements" must be updated as a whole. It should be set once when measurement is complete, not incrementally.
      // Metrics can be omitted if they weren't successfully measured; that is, the peer is unreachable.
      // If a "measurements" object is set, it can't contain an entry for the member's own address.
      "measurements": {
        "e69c43a8": {
          "bandwidthDown": 19342,  // Kilobits per second.
          "bandwidthUp": 944,  // Kilobits per second.
          "custom": { }
        }

      // QoS measurements by game-server connection string. Like all fields, "serverMeasurements" must be updated as a whole, so it should be set once when measurement is complete.
      // If empty, it means that none of the measurements were completed within the "serverMeasurementTimeout".
      "serverMeasurements": {
        "server farm a": {
          "latency": 233  // Milliseconds.
        }
      },

      // Subscriptions for shoulder taps on session changes. The "profile" indicates which session changes to tap and other properties of the registration like the minimum time between taps.
      // The subscription is named with a title-generated GUID that's also sent back with the tap as a context ID.
      // Subscriptions can be added and removed individually, without affecting other subscriptions in the "subscriptions" object.
      // To remove a subscription, set its context ID to null.
      // (Like the "ready" and "active" flags, the "subscriptions" data is copied out and maintained internally, so the normal replace-all rule on system fields doesn't apply to "subscriptions".)
      // Can't be set on large sessions.
      "subscriptions": {
        "961dc162-3a8c-4982-b58b-0347ed086bc9": {
          "profile": "party",  // Or "matchmaking", "initialization", "roster", "queuehost", or "queue".
          "onBehalfOfTitleId": "3948320593",  // Optional decimal title ID of the registered channel. If not set, the title ID is taken from the token.
        },
        "709fef70-4638-4b94-905b-24cb02706eb5": null
      }
    }

Éléments de serveur

Les serveurs sont des entités non utilisateurs qui ont rejoint une session ou y ont été invitées. Les objets JSON associés sont /servers/{server-name}/constants/system et /servers/{server-name}/properties/system. Ces objets ne peuvent être écrits que par des serveurs.

L’objet /servers/{server-name}/constants/system n’est pas utilisé actuellement.

Configuration de session

Vous pouvez contrôler la configuration des sessions des manières suivantes.

Utiliser des modèles de session ingérés via Partner Center.
Utiliser des appels aux API multijoueur et de matchmaking ou aux API REST. Vous devez tout de même utiliser un modèle, mais celui-ci n’a pas besoin de contenir les valeurs que vous souhaitez configurer. Notez que votre titre ne peut pas remplacer les constantes déjà définies dans le modèle.

Un document JSON distinct est fourni pour définir la session elle-même. En outre, vous devez implémenter toute fonctionnalité de wrapper requise pour un titre particulier. Le contenu des documents JSON et tout code de wrapper doivent se refléter précisément et refléter la dernière version de contrat de modèle. Le schéma d’une session est versionné avec la version de session (version majeure) et la révision du protocole (version mineure). Les versions sont combinées dans l’en-tête X-Xbl-Contract-Version sous la forme « 100 * majeure + mineure ». Par exemple, un titre v1.7 inclut l’en-tête suivant dans chaque requête REST, en supposant la dernière version de contrat de modèle 107 : X-Xbl-Contract-Version: 107.

Nous recommandons à la plupart des titres (utilisant XBOX Services API (XSAPI)) d’utiliser la version de contrat 105 et la version de modèle de session 107.

Modèles de session

Chaque modèle de session est un document JSON, faisant partie de la configuration de service, qui définit le cadre de la session en cours de création et fournit les constantes de la nouvelle session. Pour plus d’informations, consultez Modèles de session multijoueur. Retour en haut de cette rubrique.

Fonctionnalités de session

Les fonctionnalités (capabilities) sont des constantes de la session MPSD qui configurent le comportement que MPSD doit appliquer à cette session. Le plus souvent, vous utilisez Partner Center pour définir les fonctionnalités dans le modèle de session. Les fonctionnalités sont définies dans l’objet /constants/system/capabilities. Si aucune fonctionnalité n’est nécessaire, utilisez un objet capabilities vide.

Les titres ne modifient presque jamais les fonctionnalités de session et n’y accèdent presque jamais à l’aide de l’API multijoueur ou de l’API de matchmaking.

Les fonctionnalités de session sont représentées par la structure XblMultiplayerSessionCapabilities. Ce sont des valeurs booléennes qui indiquent ce que la session peut prendre en charge.

Connectivité
Jeu (gameplay)
Grande taille
Connexion requise pour les membres actifs

La structure XblMultiplayerSessionConstants contient un membre SessionCapabilities (de type XblMultiplayerSessionCapabilities) qui définit les propriétés suivantes, liées aux fonctionnalités de session.

CapabilitiesConnectivity
CapabilitiesGameplay
CapabilitiesLarge

Si le titre définit une fonctionnalité de session dynamique, la propriété correspondante est définie sur true pour les constantes de session.

Retour en haut de cette rubrique.

Taille de session

La taille d’une session MPSD est déterminée par le nombre de membres de cette session.

Taille maximale de session

La taille maximale d’une session est le nombre maximal de membres qu’elle peut accueillir. Elle est représentée par la propriété XblMultiplayerSessionConstants::MaxMembersInSession. Le nombre maximal de membres est défini dans l’objet /constants/system. La taille maximale de session est comprise entre 1 et 100 membres et vaut 100 par défaut si elle n’est pas définie lors de la création. Si la taille requise dépasse 100, la session est appelée « grande » session et est définie de manière particulière.

Déconnexion

Définir une taille maximale pour une session peut faire apparaître un emplacement libre comme occupé dans certains scénarios de déconnexion. Par exemple, si un joueur est déconnecté à la suite d’une panne réseau ou d’une coupure de courant, ce délai n’est pas immédiatement reflété dans la session. Le membre est défini sur Inactive à l’aide de la fonctionnalité de détection des déconnexions. Pour plus d’informations, consultez la section Gestion des notifications de modification MPSD et détection des déconnexions de la rubrique Vue d’ensemble de Multiplayer Session Directory. En comparaison, un maillage de pairs qui utilise une pulsation (heartbeat) pour détecter une déconnexion en a souvent connaissance en deux à trois secondes et peut libérer immédiatement l’emplacement du joueur. Cependant, l’arbitre ne peut pas retirer d’autres membres.

Grandes sessions

Une grande session MPSD peut compter jusqu’à 1 000 membres, mais certaines fonctionnalités de session y sont désactivées, comme l’obtention de la liste de tous les membres. Le caractère « grande » d’une session est représenté par la propriété XblMultiplayerSessionCapabilities::Large. Cette propriété est définie sur true pour indiquer une grande session. La fonctionnalité « large » est indiquée dans l’objet /constants/system/capabilities. Pour plus d’informations, consultez Fonctionnalités de session. Retour en haut de cette rubrique.

États des utilisateurs de session

MPSD définit un état d’utilisateur comme le statut d’un utilisateur ajouté à une session. Les états d’utilisateur possibles sont définis par l’énumération XblMultiplayerSessionStatus. L’utilisateur est également considéré comme ayant le statut « disponible » avant d’être ajouté à une session. Vous pouvez utiliser XblMultiplayerSessionCurrentUserSetStatus pour modifier l’état de l’utilisateur de la session. Pour REST, effectuez cette modification en définissant correctement /members/{index}/properties/system dans le document JSON de la session de jeu.

État d’utilisateur Reserved

L’utilisateur est placé dans l’état Reserved lorsque l’arbitre l’a sélectionné pour occuper l’un des emplacements libres de la session. Dans cet état, l’utilisateur n’a pas encore officiellement accepté l’invitation à la session ni rejoint la session pour commencer à se connecter aux pairs.

État d’utilisateur Active

Lorsqu’un utilisateur est dans l’état Active, le titre a rejoint la session pour le compte de l’utilisateur, et celui-ci participe activement à la session. L’utilisateur reste dans cet état tant qu’il joue. Lors de son premier lancement, un titre doit vérifier si l’utilisateur est déjà membre de sessions, généralement en vérifiant l’état de session. Si l’utilisateur est membre d’une session, le titre peut accéder directement au jeu et définir tous les membres locaux participants sur l’état Active. Un utilisateur doit rester dans l’état Active tant qu’il joue dans la session. Si un utilisateur quitte la session via l’interface utilisateur du jeu, il doit être retiré de la session par un appel à XblMultiplayerSessionLeave. Si l’utilisateur ne s’éloigne du jeu que temporairement, par exemple lorsque le titre est contraint, le titre doit conserver l’utilisateur dans l’état Active pendant une durée raisonnable. Il convient de passer l’état de l’utilisateur à Inactive si celui-ci n’est pas revenu au bout d’une période définie par le titre.

État d’utilisateur Inactive

Dans l’état Inactive, l’utilisateur n’est pas engagé dans le jeu pour le moment, mais il dispose toujours d’un emplacement réservé dans la session. Autrement dit, l’utilisateur est « non actif ». C’est la console de l’utilisateur lui-même qui est chargée de le définir sur l’état Inactive dans la session. L’arbitre ne peut pas le faire. Voici des exemples de scénarios dans lesquels un utilisateur est placé dans l’état Inactive :

Le titre reçoit un événement Suspending.
L’utilisateur est inactif (aucune entrée ni réponse de la manette) depuis une période définie par le titre. Nous recommandons deux minutes pour un jeu multijoueur compétitif.
Le titre est en mode contraint depuis plus de deux minutes ou depuis une période définie par le titre. Ce délai d’expiration du mode contraint correspond à la durée pendant laquelle un utilisateur est susceptible de s’éloigner du titre pour utiliser une application associée ou une autre expérience liée au titre.
L’utilisateur a été déconnecté de la session de manière inattendue. Pour plus d’informations, consultez la section Gestion des notifications de modification MPSD et détection des déconnexions de la rubrique Vue d’ensemble de Multiplayer Session Directory.

Si le titre démarre et que l’état d’un membre de session particulier est défini sur Inactive, c’est que le titre a été suspendu ou que l’utilisateur est resté inactif trop longtemps dans la session. Comme le titre est relancé, cela indique que l’utilisateur souhaite poursuivre la session de jeu à laquelle il appartient. Si l’état de l’utilisateur est Active au lancement du titre, cette situation est probablement due à une déconnexion réseau ou à un autre scénario dans lequel le titre n’a pas pu définir l’utilisateur sur Inactive avant d’être interrompu. Dans les deux cas, votre titre doit tenter de reconnecter l’utilisateur au jeu et permettre aux autres utilisateurs de continuer à jouer, ou retirer l’utilisateur de la session.

État de l’utilisateur à la fin de la session

Lorsque la session est terminée, le jeu s’arrête. Le titre doit permettre à tous les utilisateurs de se retirer à l’aide de XblMultiplayerSessionLeave. Les activités de session associées aux utilisateurs sont automatiquement effacées lorsqu’ils quittent la session. Retour en haut de cette rubrique.

Visibilité et possibilité de jonction

L’accès aux sessions est contrôlé au niveau de MPSD par deux paramètres : la visibilité de la session et la possibilité de la rejoindre. Les recommandations de visibilité et de possibilité de jonction formulées dans cette rubrique s’appliquent aux scénarios de titre les plus courants. Les titres doivent suivre ces paramètres dans la mesure du possible. Ils doivent utiliser une logique interne au titre pour décider en dernier ressort, de manière définitive, si un nouveau joueur est admis dans une session.

Visibilité de la session

La visibilité de la session est représentée par une constante définie lors de la création de la session. Elle est généralement définie dans le modèle de session et détermine quels types d’utilisateurs disposent d’un accès en lecture et en écriture à une session. Les valeurs possibles de la visibilité de la session sont définies par XblMultiplayerSearchHandleGetVisibility. Les valeurs autorisées pour la constante de visibilité dans un fichier JSON sont open, visible et private.

Visibilité recommandée pour les sessions de jeu : open

Les sessions de jeu ouvertes ne nécessitent pas de réservations de joueurs, ce qui simplifie le processus d’invitation. L’arbitre ne réserve pas de joueurs dans MPSD après l’envoi d’une invitation ; il se contente de suivre localement les joueurs invités. Par conséquent, les joueurs peuvent se connecter immédiatement à l’arbitre et déterminer s’ils doivent rejoindre une session, s’ils sont refusés ou s’ils doivent patienter (si les joueurs en attente sont pris en charge). L’arbitre a l’autorité finale. Il répond au nouveau membre et lui indique s’il doit rester dans la session ou la quitter. L’utilisation de la visibilité ouverte pour une session de jeu exige que le joueur invité lance un titre et se connecte à l’arbitre avant que la décision finale ne soit prise. Vous pouvez afficher un message d’erreur à l’utilisateur si une session est pleine ou si une invitation a été refusée. Pour établir une connexion à l’arbitre, une adresse d’appareil sécurisée est requise. La propriété XblMultiplayerSessionProperties::HostDeviceToken permet de savoir quel membre est l’arbitre actuel d’une session et quelle adresse d’appareil sécurisée un joueur invité doit utiliser pour se connecter.

Possibilité de jonction de la session

La possibilité de jonction de la session détermine quels types d’utilisateurs peuvent rejoindre une session. Elle peut être définie de manière dynamique au cours d’une session. Les valeurs possibles de la possibilité de jonction de la session sont les suivantes.

None (par défaut) : aucune restriction ne s’applique quant aux personnes pouvant rejoindre la session.
Local : seuls les utilisateurs locaux peuvent rejoindre la session.
Followed : seuls les utilisateurs locaux et les utilisateurs suivis par d’autres membres de la session peuvent rejoindre la session sans réservation.

Un arbitre de session peut créer une session privée au moyen du paramètre de possibilité de jonction. Définir la possibilité de jonction sur local ou followed restreint l’accès à la session et la rend privée. L’arbitre doit également suivre la possibilité de jonction de la session afin que les anciennes invitations à la session puissent être refusées au niveau de l’hôte si nécessaire. Par exemple, si des joueurs invités n’arrivent pour rejoindre une session qu’une fois celle-ci déjà pleine, l’arbitre peut indiquer à ces joueurs que la session a été verrouillée et qu’ils doivent la quitter automatiquement. Retour en haut de cette rubrique.

Délais d’expiration des sessions

Les sessions peuvent être modifiées par des minuteurs et d’autres événements externes. Les délais d’expiration des sessions définissent les périodes pendant lesquelles les membres de la session peuvent rester dans des états spécifiques avant d’être automatiquement rendus inactifs ou retirés de la session. MPSD prend également en charge des délais d’expiration pour gérer la durée de vie des sessions.

Pour la version de contrat de modèle 104 ou 105, les paramètres de délai d’expiration sont définis dans /constants/system/timeouts ou dans l’objet d’initialisation gérée. Pour la version 107 ou ultérieure, les paramètres sont définis individuellement dans /constants/system ou dans l’objet d’initialisation gérée.

Lorsqu’un minuteur expire, MPSD ne met pas automatiquement à jour la session et n’informe pas immédiatement l’arbitre des modifications. Les états de la session et des délais d’expiration ne sont mis à jour qu’immédiatement avant l’envoi d’une requête de lecture ou d’écriture. Cette mise à jour immédiate garantit que les données renvoyées sont les plus récentes.

Les délais d’expiration des sessions ne se cumulent pas. Un seul est appliqué pour une transition d’état de chaque membre de la session lors d’une mise à jour.

Délais d’expiration actuellement définis

Cette section décrit les délais d’expiration actuellement définis par MPSD.

Tous les délais d’expiration sont exprimés en millisecondes.
La valeur 0 est autorisée et indique une expiration immédiate.
Un délai d’expiration sans valeur est considéré comme infini.

Comme les délais d’expiration ont des valeurs par défaut, vous devez spécifier explicitement null pour un délai d’expiration infini.

evaluationTimeout

Ce délai d’expiration indique la durée dont dispose un membre de la session pour prendre et charger la décision d’évaluation. Si aucune décision n’est reçue, cela compte comme un échec. Ce délai d’expiration se trouve dans l’objet d’initialisation gérée.

inactiveRemovalTimeout

Ce délai d’expiration s’applique à un membre qui a rejoint une session, mais qui n’est pas engagé dans le jeu pour le moment. Par défaut, le membre est retiré de la session au bout de deux heures.

Ce délai d’expiration est appelé délai d’expiration inactive pour la version de contrat de modèle 104 ou 105.

Dans de nombreux cas, nous recommandons de définir le délai d’expiration inactive sur 0. Ainsi, tout utilisateur placé dans l’état Inactive est immédiatement retiré de la session et l’emplacement correspondant est libéré. Ce comportement est souhaitable pour la plupart des jeux multijoueurs compétitifs : si un utilisateur devient inactif ou atteint l’état Inactive, un nouveau joueur peut être ajouté rapidement. Pour les jeux coopératifs ou d’autres conceptions multijoueurs, vous pouvez souhaiter que votre titre laisse aux utilisateurs plus de temps pour se reconnecter s’ils sont déconnectés ou désengagés du titre pendant un certain temps. Notez qu’aucune solution unique ne convient à tous les scénarios de conception.

joinTimeout

Ce délai d’expiration indique le nombre de millisecondes dont dispose un utilisateur pour rejoindre la session. Les réservations des utilisateurs qui ne parviennent pas à rejoindre la session sont supprimées. Ce délai d’expiration se trouve dans l’objet d’initialisation gérée.

measurementTimeout

Ce délai d’expiration indique la durée dont dispose un membre de la session pour charger ses mesures. Un membre qui ne parvient pas à charger ses mesures est marqué avec le motif d’échec “timeout”. Ce délai d’expiration se trouve dans l’objet d’initialisation gérée.

Pendant le matchmaking, un délai d’expiration de 45 secondes est appliqué aux mesures QoS. Par conséquent, nous vous recommandons d’utiliser un délai d’expiration des mesures inférieur ou égal à 30 secondes pendant le matchmaking.

readyRemovalTimeout

Ce délai d’expiration s’applique à un membre qui a rejoint la session et tente d’entrer dans le jeu. Cela signifie généralement que le shell a fait rejoindre la session à l’utilisateur pour le compte du titre et que celui-ci est en cours de lancement. Par défaut, le membre est retiré de la session et placé dans l’état Inactive au bout de trois minutes.

Ce délai d’expiration est appelé délai d’expiration ready pour la version de contrat 104 ou 105.

reservedRemovalTimeout

Ce délai d’expiration s’applique à un membre qui a été ajouté à la session par quelqu’un d’autre, mais qui n’a pas encore rejoint la session. À l’expiration du délai, la réservation est supprimée et le membre est considéré comme inactif. La valeur par défaut est de 30 secondes.

Ce délai d’expiration est appelé délai d’expiration reserved pour la version de contrat 104 ou 105.

sessionEmptyTimeout

Ce délai d’expiration indique le nombre de millisecondes après lequel une session devenue vide est supprimée. La valeur par défaut est 0.

Ce délai d’expiration est appelé délai d’expiration sessionEmpty pour la version de contrat 104 ou 105.

Exemple de délai d’expiration de session

Une session démarre avec quatre joueurs.
Deux joueurs, A et B, sont déconnectés en raison d’une coupure de courant. Leur statut dans le jeu reste Active.
Les deux autres joueurs, C et D, quittent correctement la session à l’aide de XblMultiplayerSessionLeave.
La session reste ouverte. Les joueurs A et B sont déconnectés, mais toujours dans l’état Active.
Quelques jours plus tard, le joueur A revient et lance le jeu.
Le jeu du joueur A recherche les sessions dont le joueur A est membre (effectue une lecture) et trouve la session orpheline datant de quelques jours.
La session effectue une vérification de présence des deux joueurs qui s’y trouvent toujours (A et B).
1. Comme le joueur A exécute le titre, la vérification de présence du joueur A réussit. L’état Active du joueur dans le match reste inchangé.
2. Le joueur B n’exécute pas le titre. Par conséquent, la vérification de présence du joueur B échoue. Le service définit l’état du joueur B sur Inactive. À ce stade, le délai d’expiration inactive démarre pour le joueur B.
Le joueur A quitte correctement la session à l’aide de la méthode XblMultiplayerSessionLeave.
Le délai d’expiration inactive du joueur B expire ; celui-ci est retiré de la session lors de la prochaine lecture ou écriture effectuée par quiconque.
La session ne compte plus aucun membre et est supprimée du service.

Si le délai d’expiration inactive de la session de l’exemple est défini sur 0, le joueur B expire immédiatement après la vérification de présence de l’étape 7.1 et est probablement retiré par l’écriture de la session. Dans ce cas, la session se ferme sans nécessiter de lecture ou d’écriture supplémentaire. Retour en haut de cette rubrique.

Plusieurs utilisateurs connectés sur une même console

Lorsque plusieurs utilisateurs sont connectés sur la même console, il est possible que certains se trouvent dans une session de jeu tandis que d’autres ne sont pas dans la session ou ne sont pas actifs dans le titre actuel. Des invitations de jeu peuvent également être reçues et acceptées pour plusieurs utilisateurs, ce qui a une incidence sur l’appartenance à la session de jeu. Tenez compte de ces informations pour votre titre afin qu’il puisse gérer correctement tous les scénarios d’appartenance aux sessions. Dans un scénario courant, un nouveau joueur se connecte, devient actif dans le jeu et doit être ajouté à une session de jeu existante. Comme pour la création d’une nouvelle session de jeu, un titre ne doit ajouter un utilisateur qu’au moment opportun pendant le jeu. Lorsque plusieurs utilisateurs sont connectés, un ou plusieurs d’entre eux peuvent également recevoir des invitations à une autre session de jeu. Les titres n’ont pas besoin de gérer ces scénarios de manière spécifique. Les événements d’état de session et de membre informent le titre de toute mise à jour de la session de jeu et de l’appartenance des utilisateurs. Pour gérer plusieurs utilisateurs connectés dans une session en ligne, le titre s’abonne aux shoulder taps pour tous les utilisateurs, en utilisant un objet XboxLiveContext Class distinct pour chacun. Le titre utilise la propriété XblMultiplayerSessionInfo::ChangeNumber pour identifier les modifications particulières de la session et ignorer les shoulder taps en double. Retour en haut de cette rubrique.

Gestion du cycle de vie des processus

Comme un titre non multijoueur, un titre dans une session multijoueur peut être confronté à des événements de cycle de vie des processus tels que la suspension et l’arrêt du titre. Par conséquent, l’arbitre de session doit enregistrer périodiquement l’état de la session. Si l’arbitre est suspendu, le titre doit tenter une migration d’arbitre et enregistrer l’état du jeu de manière appropriée. Un nouvel arbitre peut alors restaurer l’état de la session. Il est alors possible de suspendre une session multijoueur complète et de la reprendre plus tard si la session est toujours valide dans MPSD. Un seul pair désigné, généralement l’hôte de la partie, doit mettre à jour l’état global du jeu.

Stockage des métadonnées de jeu

Un titre stocke les métadonnées de jeu dans la session MPSD. Les métadonnées de jeu sont les informations nécessaires pour afficher les données de session et permettre au titre de trouver et de rejoindre la session de jeu. Le titre stocke les métadonnées propres à chaque joueur dans la section des propriétés personnalisées du membre de la session. Par exemple, la couleur du joueur et son arme préférée pour la session. Les métadonnées valables pour toute la session, comme la carte actuelle, sont stockées dans la section des propriétés personnalisées globales de la session MPSD.

Stockage de l’état du jeu

L’état du jeu est stocké dans TMS à l’aide du service Title Storage. Le stockage à cet emplacement permet à un titre de migrer l’arbitre sans problème d’autorisations. Pour plus d’informations, consultez Migration d’un arbitre.

Le titre ne doit pas tenter d’enregistrer l’état du jeu dans TMS plus d’une fois toutes les cinq minutes, sauf s’il est en cours de suspension.

Retour en haut de cette rubrique.

Nettoyage des sessions inactives

Si sessionEmptyTimeout est défini sur 0, une session MPSD est automatiquement supprimée lorsque le dernier joueur la quitte. Pour savoir comment éviter qu’une session inutilisée ne contienne encore des joueurs après un plantage ou une déconnexion, consultez la section Gestion des notifications de modification MPSD et détection des déconnexions de la rubrique Vue d’ensemble de Multiplayer Session Directory. Une gestion incorrecte des sessions inutilisées après un plantage ou une déconnexion peut causer des problèmes lorsqu’un titre interroge les sessions d’un joueur. Nous vous recommandons de nettoyer les sessions inactives en faisant interroger par le titre toutes les sessions d’un utilisateur particulier à l’aide d’un appel à XblMultiplayerGetSessionAsync, puis en évaluant les sessions. Lorsque le titre rencontre une session obsolète, il appelle XblMultiplayerSessionLeave pour tous les joueurs locaux de la session. Cet appel finit par ramener le nombre de membres à 0 et nettoie les sessions. Retour en haut de cette rubrique.

Arbitre de session

Certaines méthodes multijoueurs ne doivent être appelées que par un seul client au sein d’une session de jeu. Ce client est l’une des consoles participant à la session ; on l’appelle l’arbitre, ou l’hôte. Si au moins un membre de la session est dans une partie, la session doit avoir un arbitre pour surveiller les jonctions en cours de partie.

Définition de l’arbitre

Lorsqu’une session est créée par le client, celui-ci désigne une console comme arbitre. Pour plus d’informations, consultez la section Définir un arbitre pour une session MPSD de la rubrique Tâches multijoueurs.

Enregistrement de l’état de la session

Comme décrit dans la section Gestion du cycle de vie des processus, l’arbitre doit enregistrer périodiquement l’état de la session. Un nouvel arbitre doit pouvoir restaurer l’état de la session en cas de migration d’arbitre par le titre. Pour plus d’informations, consultez Migration d’un arbitre.

Gestion des membres de la session de jeu et des jonctions en cours de partie

Le rôle le plus important de l’arbitre de session est de gérer les utilisateurs qui entrent dans la session de jeu pour jouer. Cela comprend la gestion des invitations de jeu, la notification des joueurs en attente et la prise en charge des joueurs qui quittent la partie.

Réception des notifications

L’arbitre doit être à l’écoute des nouveaux joueurs qui souhaitent rejoindre la session de jeu à l’aide de XblMultiplayerSessionChangedHandler.

Recherche de joueurs pour occuper les emplacements libres de la session de jeu

L’arbitre trouve des joueurs pour occuper les emplacements libres de la session de jeu à l’aide de l’une des opérations suivantes.

Si votre titre utilise une session de lobby ou un autre mécanisme pour autoriser les jonctions différées, trouvez de nouveaux membres de session à l’aide de ce mécanisme.
Créez une autre session de ticket de match.

Pour plus d’informations, consultez la section Remplir les emplacements de session libres pendant le matchmaking de la rubrique Tâches multijoueurs.

Gestion des membres invités de la session

L’arbitre doit surveiller les membres invités de la session et appliquer un intervalle minimal entre les invitations adressées à un même utilisateur. Pour plus d’informations, consultez la section Envoyer des invitations de jeu de la rubrique Tâches multijoueurs.

Dernière modification le 8 octobre 2026

⌘I

​Vue d’ensemble des sessions

​Numéro de version de contrat

​Référence de session

​Éléments d’une session

​Constantes de session

​Propriétés de session

​Constantes des membres

​Propriétés des membres

​Éléments de serveur

​Configuration de session

​Modèles de session

​Fonctionnalités de session

​Taille de session

​Taille maximale de session

​Déconnexion

​Grandes sessions

​États des utilisateurs de session

​État d’utilisateur Reserved

​État d’utilisateur Active

​État d’utilisateur Inactive

​État de l’utilisateur à la fin de la session

​Visibilité et possibilité de jonction

​Visibilité de la session

​Visibilité recommandée pour les sessions de jeu : open

​Possibilité de jonction de la session

​Délais d’expiration des sessions

​Délais d’expiration actuellement définis

​evaluationTimeout

​inactiveRemovalTimeout

​joinTimeout

​measurementTimeout

​readyRemovalTimeout

​reservedRemovalTimeout

​sessionEmptyTimeout

​Exemple de délai d’expiration de session

​Plusieurs utilisateurs connectés sur une même console

​Gestion du cycle de vie des processus

​Stockage des métadonnées de jeu

​Stockage de l’état du jeu

​Nettoyage des sessions inactives

​Arbitre de session

​Définition de l’arbitre

​Enregistrement de l’état de la session

​Gestion des membres de la session de jeu et des jonctions en cours de partie

​Réception des notifications

​Recherche de joueurs pour occuper les emplacements libres de la session de jeu

​Gestion des membres invités de la session

Vue d’ensemble des sessions

Numéro de version de contrat

Référence de session

Éléments d’une session

Constantes de session

Propriétés de session

Constantes des membres

Propriétés des membres

Éléments de serveur

Configuration de session

Modèles de session

Fonctionnalités de session

Taille de session

Taille maximale de session

Déconnexion

Grandes sessions

États des utilisateurs de session

État d’utilisateur Reserved

État d’utilisateur Active

État d’utilisateur Inactive

État de l’utilisateur à la fin de la session

Visibilité et possibilité de jonction

Visibilité de la session

Visibilité recommandée pour les sessions de jeu : open

Possibilité de jonction de la session

Délais d’expiration des sessions

Délais d’expiration actuellement définis

evaluationTimeout

inactiveRemovalTimeout

joinTimeout

measurementTimeout

readyRemovalTimeout

reservedRemovalTimeout

sessionEmptyTimeout

Exemple de délai d’expiration de session

Plusieurs utilisateurs connectés sur une même console

Gestion du cycle de vie des processus

Stockage des métadonnées de jeu

Stockage de l’état du jeu

Nettoyage des sessions inactives

Arbitre de session

Définition de l’arbitre

Enregistrement de l’état de la session

Gestion des membres de la session de jeu et des jonctions en cours de partie

Réception des notifications

Recherche de joueurs pour occuper les emplacements libres de la session de jeu

Gestion des membres invités de la session