> ## Documentation Index > Fetch the complete documentation index at: https://devdocs.xbox.com/llms.txt > Use this file to discover all available pages before exploring further. # Visibilité et possibilité de jonction des sessions de jeu > Explique les paramètres de visibilité (open, visible, private) et de possibilité de jonction des sessions de jeu MPSD, et recommande des configurations pour les invitations et jonctions multijoueurs XBOX. Sur XBOX One (ou version ultérieure), les paramètres de *visibilité* et de *possibilité de jonction* des sessions de jeu et des groupes de jeu contrôlent l'accès aux expériences multijoueurs. Pour offrir une excellente expérience utilisateur lors de la jonction de sessions et de l'invitation de joueurs dans des sessions et des groupes de jeu, vous devez comprendre ces paramètres. Cette rubrique passe en revue les différences entre visibilité et possibilité de jonction. Elle présente également les paramètres spécifiques que nous recommandons aux titres d'utiliser pour offrir à leurs utilisateurs le meilleur flux multijoueur. ## Visibilité des sessions de jeu L'accès aux sessions Multiplayer Session Directory (MPSD) est régi par deux paramètres : la *visibilité* et la *possibilité de jonction* de la session. Ces paramètres permettent de limiter l'accès aux sessions au niveau de MPSD. Le premier aspect du contrôle d'accès est la visibilité de la session. La visibilité de la session est une constante définie au moment de la création de la session. La visibilité de la session 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 du paramètre de visibilité sont les suivantes. * **Open :** tous les utilisateurs peuvent lire et écrire dans la session. * **Visible :** tous les utilisateurs peuvent lire la session, mais seuls les joueurs ayant rejoint la session ou réservés peuvent y écrire. * **Private :** seuls les joueurs ayant rejoint la session ou réservés peuvent la lire ou y écrire. Définir la visibilité sur « private » peut obliger le joueur invité à réessayer l'appel `join()`. Si une invitation est envoyée au moyen de l'interface utilisateur de la plateforme, elle peut être reçue par un autre joueur avant que ce joueur n'ait été réservé dans la session. Cette condition de concurrence peut faire échouer un appel `join()` pour un joueur invité, car les sessions « private » ou « visible » exigent une réservation pour le joueur qui rejoint. S'il n'existe aucune réservation, une erreur d'accès à la session (HTTP/403) est générée. Le joueur invité doit alors réessayer l'opération `join()`. Cependant, les nouvelles tentatives ne doivent pas avoir lieu plus d'une fois toutes les cinq secondes. Nous recommandons aux titres de définir la visibilité de la session sur « open » afin d'éviter les conditions de concurrence pendant le flux de jonction d'un joueur. ## Possibilité de jonction des sessions de jeu Le second aspect du contrôle d'accès est la possibilité de jonction. Elle peut être définie de manière dynamique pendant la durée de vie de la session et détermine quels types d'utilisateurs peuvent rejoindre une session. Les valeurs de la possibilité de jonction de la session sont les suivantes. * **None :** (valeur 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 ou un hôte 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 à une session de jeu et la rend privée. En outre, l'arbitre ou l'hôte de la session doit suivre la possibilité de jonction d'une 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 ou un groupe qu'une fois la session déjà pleine, l'arbitre ou l'hôte peut indiquer aux joueurs qui rejoignent que la session a été verrouillée. Ils doivent alors quitter automatiquement la session ou le groupe. La possibilité de jonction des sessions de jeu n'est pas reflétée dans l'interface utilisateur de l'application Party. Même si la possibilité de jonction est restreinte, l'interface d'invitation de l'application Party et `ShowSendInvitesAsync` autorisent les invitations à la session de jeu. ## Possibilité de jonction des groupes de jeu En plus de contrôler la session MPSD, le titre contrôle également l'état de possibilité de jonction du groupe de jeu. Ce paramètre permet de limiter l'accès au groupe de jeu au niveau du groupe. La possibilité de jonction du groupe peut être modifiée dynamiquement lors de la création du groupe de jeu. L'état de possibilité de jonction d'un groupe de jeu est reflété dans l'interface d'invitation de Party. L'état de possibilité de jonction peut être défini comme suit : * **Invite-only :** ce paramètre exige une invitation pour rejoindre le groupe de jeu. * **Joinable by Friends :** (valeur par défaut) ce paramètre exige une relation d'amitié pour qu'un joueur puisse rejoindre le groupe de jeu (pour rejoindre un groupe, un membre du groupe doit suivre le joueur qui rejoint). La possibilité de jonction peut servir à créer un groupe de jeu accessible uniquement sur invitation. Pour restreindre l'accès à un groupe et exiger que les joueurs aient reçu une invitation pour le rejoindre, la possibilité de jonction doit être définie sur « invite-only ». La possibilité de jonction du groupe n'influe pas sur la possibilité de jonction de la session. Elle est cependant reflétée dans l'interface utilisateur de l'application Party. Les joueurs peuvent modifier manuellement la possibilité de jonction du groupe dans l'application Party, en dehors d'un titre. ## Recommandations Les recommandations suivantes s'appliquent aux scénarios de titre les plus courants. Les titres doivent suivre ces paramètres dans la mesure du possible, et utiliser une logique interne au titre pour décider en dernier ressort, de manière définitive, si un nouveau joueur est admis dans la session. ### Visibilité recommandée pour les sessions de jeu : open Les sessions de jeu ouvertes ne nécessitent pas de réservations de joueurs. Cela simplifie le flux des invitations. L'arbitre ou l'hôte de la session ne réserve pas de joueurs dans le document de session après l'envoi d'une invitation. Il se contente de suivre localement les joueurs invités. Cela permet aux joueurs de se connecter immédiatement à l'hôte et de 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 ou l'hôte a l'autorité finale : il répond au nouveau membre et lui indique s'il doit rester dans la session ou la quitter. Cela exige que le joueur invité lance un titre et se connecte à l'arbitre ou à l'hôte avant que la décision finale ne soit prise. Il est acceptable d'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 ou à l'hôte, une adresse d'appareil sécurisée (Secure Device Address) est requise. Le `HostDeviceToken` de la session doit être utilisé pour indiquer quel membre est l'arbitre ou l'hôte actuel d'une session et à quelle adresse d'appareil sécurisée un joueur invité doit se connecter. ### Possibilité de jonction recommandée pour les sessions de jeu : valeur par défaut (*non définie*) Actuellement, la possibilité de jonction des sessions de jeu n'influe pas sur l'interface utilisateur de l'application Party et n'est pas présentée à l'utilisateur. Pour simplifier le flux du titre, la possibilité de jonction de la partie doit rester à sa valeur par défaut, et toute l'autorité en matière de jonction doit être gérée par l'arbitre ou l'hôte. ### Possibilité de jonction recommandée pour les groupes de jeu La possibilité de jonction des groupes de jeu dépend du type de session qu'un titre cherche à proposer à un utilisateur. Les deux scénarios sont les suivants. * **Partie ouverte :** pour une partie ouverte, la possibilité de jonction du groupe de jeu doit rester à sa valeur par défaut, « Joinable by Friends ». Cela permet aux amis de rejoindre le groupe de jeu (et, par extension, la session de jeu) sans invitation. * **Partie privée :** pour une partie privée ou fermée, la possibilité de jonction du groupe de jeu doit être définie sur « invite only ». Cela empêche d'autres joueurs de rejoindre le groupe (et, par extension, la session de jeu) sans invitation. Les joueurs peuvent modifier manuellement la possibilité de jonction d'une session de jeu au moyen de l'application Party. Pour les deux types de parties, l'arbitre ou l'hôte doit rester l'autorité finale pour déterminer qui est accepté dans une session. Cela permet de gérer les conditions de concurrence qui peuvent survenir lors du passage d'un flux de jeu ouvert à un flux privé. Si l'arbitre ou l'hôte refuse un joueur, l'instance du titre refusée doit retirer le joueur de la session et afficher une interface utilisateur dans le jeu permettant également au joueur de quitter le groupe. ### Taille maximale de session Le nombre maximal de membres d'une session peut servir à limiter le nombre de joueurs qui rejoignent une session de jeu. Cependant, cette limite 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 comme inactif dès que le service Presence détecte la déconnexion (jusqu'à 20 secondes). Le joueur est ensuite retiré une fois le délai d'expiration inactive écoulé. 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 ou l'hôte ne peut pas retirer d'autres membres. Pour résoudre ce problème, le nombre maximal de membres d'une session doit toujours être supérieur au nombre maximal de joueurs que le titre prend réellement en charge. Par exemple, si le nombre de joueurs est de 8, le titre doit définir la taille maximale de session sur 12. Ainsi, de nouveaux joueurs peuvent rejoindre la session, même si les joueurs précédents n'ont pas encore expiré. L'arbitre ou l'hôte détermine si la session est pleine, puis définit une propriété de session personnalisée qui indique si de nouveaux joueurs peuvent encore la rejoindre (`IsFull` : "true"). Cela permet aux joueurs qui rejoignent de vérifier rapidement si la session est joignable. L'arbitre ou l'hôte doit également tenir à jour une propriété personnalisée qui indique, par index, quels membres ont expiré (par exemple, `TimedOutPlayers` : "3, 5, 9"). Cela permet aux nouveaux joueurs d'identifier correctement les membres actuels de la session. ### Notification des joueurs en attente Un titre peut prendre en charge des joueurs en attente en gérant une liste de joueurs en file d'attente, en plus du groupe de jeu. Lorsqu'un joueur se connecte à l'hôte alors que la session de jeu est pleine, il est ajouté à la liste d'attente interne de l'hôte. Le joueur en file d'attente ne rejoint pas la session de jeu, mais reste dans le groupe de jeu. Pour réduire le trafic réseau, le joueur en attente se déconnecte alors de l'hôte. 1. Lorsqu'un emplacement de la session de jeu se libère pour le joueur en attente, l'arbitre ou l'hôte ajoute une réservation pour ce joueur en appelant [XblMultiplayerSessionAddMemberReservation](/fr-CA/reference/live/xsapi-c/multiplayer_c/functions/xblmultiplayersessionaddmemberreservation). 2. À ce stade, le joueur en attente n'a pas encore connaissance de cette réservation. Par conséquent, l'arbitre ou l'hôte doit appeler la méthode `PullReservedPlayersAsync`. Cela déclenche une notification d'interface utilisateur ou une notification `GameSessionReady` pour tous les joueurs réservés, selon la configuration des notifications et l'état de focus du titre. 3. Le nouveau joueur se reconnecte à l'hôte lorsqu'il reçoit cette notification, puis rejoint la session. Un joueur peut également rester connecté à l'hôte et rejoindre la session lorsque l'hôte l'avertit qu'un emplacement est disponible. Dans ce flux, cependant, aucune notification d'interface utilisateur ne peut être affichée en dehors du titre. Les joueurs sont automatiquement retirés du groupe de jeu si le titre est suspendu ou arrêté. Les joueurs ne reçoivent alors plus aucune notification. ## Flux multijoueur client Organigramme du multijoueur client, partie 1 Organigramme du multijoueur client, partie 2 ## Related topics - [Concepts de Multiplayer Session Directory (MPSD)](/fr-CA/services/xbox-services/multiplayer/mpsd/concepts/live-mpsd-concepts-nav.md) - [Concepts](/fr-CA/services/xbox-services/multiplayer/mpsd/concepts/index.md) - [Rubriques avancées sur les sessions multijoueurs](/fr-CA/services/xbox-services/multiplayer/mpsd/concepts/live-mpsd-details.md) - [XR-064 Sessions de jeu joignables et jeu en ligne](/fr-CA/publishing/certification/xr/xr-064.md) - [Modèles de session multijoueur](/fr-CA/services/xbox-services/multiplayer/mpsd/concepts/live-session-templates.md)