Skip to main content
Utilisez cette rubrique pour comprendre comment utiliser les API de port multijoueur UDP (User Datagram Protocol) local préféré pour améliorer la fiabilité du multijoueur. Toutes les générations de consoles XBOX vous ont permis d’utiliser le port UDP 3074. Il s’agit d’un port bien connu, inscrit publiquement, destiné au trafic réseau multijoueur. Les titres du Microsoft Game Development Kit (GDK) ne font pas exception et peuvent utiliser les API de mise en réseau du port multijoueur UDP local préféré pour accéder à ce port spécial. Le port multijoueur UDP local préféré est le port local utilisé lors d’une opération subséquente de liaison de socket, par opposition au port public que les appareils distants pourraient utiliser pour se connecter à l’appareil local. Le premier n’a de sens que pour le trafic UDP, et non pour le trafic TCP (Transmission Control Protocol) et HTTP, car il cible précisément les flux réseau multijoueurs en temps réel des titres. Historiquement, le port était limité à UDP 3074. Toutefois, au cours des dernières années, une logique de repli a été introduite pour accroître la fiabilité de ce port. De plus, les utilisateurs ont pu configurer manuellement le port pour qu’il fonctionne avec leurs propres configurations réseau uniques. C’est pourquoi il n’est plus sûr de coder UDP 3074 en dur dans un titre du Microsoft Game Development Kit (GDK). Les titres du Microsoft Game Development Kit (GDK) doivent plutôt interroger dynamiquement le port actuellement configuré. Il existe trois façons de récupérer le port multijoueur UDP local préféré. Les trois variantes offrent les mêmes fonctionnalités de base. N’importe laquelle d’entre elles (ou n’importe quelle combinaison) peut être appelée par un titre du Microsoft Game Development Kit (GDK) selon ses besoins et cas d’utilisation précis. Nous recommandons fortement que tous les titres du Microsoft Game Development Kit (GDK) utilisent le port préféré pour leur trafic de jeu principal. Ce port est optimisé à la fois pour les topologies de réseau pair à pair et pour les topologies de réseau client/serveur. La plateforme du Microsoft Game Development Kit (GDK) s’assure que ce port précis est celui qui a le plus de chances de fonctionner dans l’environnement réseau particulier de chaque utilisateur. L’utilisation de ce port précis permet de tirer le meilleur parti des flux de soutien à la clientèle et de diagnostic de la plateforme, accroît la compatibilité standardisée avec la traduction d’adresses réseau (NAT), offre une fonctionnalité standardisée pour les appareils certifiés UPnP™ et identifie les paquets comme étant sensibles au temps réel pour les algorithmes de qualité de service (QoS) des routeurs et des FAI. Ce port préféré est particulièrement pertinent pour les titres qui reposent sur des topologies de réseau pair à pair. C’est le seul port qui permet aux paquets UDP entrants de traverser le pare-feu sans effectuer de traversée de pare-feu (punching). Les titres du Microsoft Game Development Kit (GDK) qui reposent sur des topologies de réseau pair à pair doivent tout de même fournir leur propre mécanisme de découverte de l’adresse IP publique et du port, ainsi qu’une solution de traversée NAT pour les clients dont le type de NAT est modéré ou strict. Le port préféré améliore le taux de réussite de ces technologies, mais ne les remplace pas. Les titres qui utilisent des topologies de réseau client/serveur bénéficient également de l’utilisation de ce port. Le dépannage, l’UPnP™ et l’identification des paquets demeurent pertinents pour les portails captifs et les autres approches de filtrage basées sur la source, courantes dans les hôpitaux, les hôtels et les résidences étudiantes. Le port préféré doit être traité comme n’importe quel autre port. Il doit être utilisé conjointement avec les API Windows Sockets 2 (Winsock). Le titre doit se lier à la fois à IPv4 et à IPv6 sur ce port ou utiliser un socket à double pile, et il doit se lier à l’adresse INADDR_ANY/in6addr_any.

Gestion des échecs de socket

Rien ne garantit que le port retourné peut être utilisé pour établir une connexion de socket réussie avec des serveurs ou des pairs particuliers. La logique habituelle de nouvelle tentative et de repli du titre doit être appliquée. Chaque fois que le socket est fermé et rouvert, le titre doit interroger de nouveau le port multijoueur UDP local préféré le plus récent, car le port peut changer au fil du temps.

Initialisation du réseau

Les trois variantes (bloquante, asynchrone et basée sur les notifications) de l’API XNetworkingQueryPreferredLocalUdpMultiplayerPort bloquent ou retardent l’achèvement ou les notifications jusqu’à ce que le réseau soit initialisé au lancement du titre et lors de la reprise. Vous pouvez attendre séparément l’initialisation du réseau conformément à la vue d’ensemble Détection de l’état d’initialisation du réseau, ou appeler ces API et attendre qu’elles retournent.

Suspension et reprise

Comme tout autre socket, le socket lié au port multijoueur UDP local préféré doit être fermé lors de la suspension et recréé lors de la reprise, après avoir attendu l’initialisation du réseau. Vous devez vous inscrire aux événements de suspension et de reprise au moyen de RegisterAppStateChangeNotification. Lors de la reprise, vous devez supposer que le port multijoueur UDP local préféré a changé et soit être à l’écoute des changements du port multijoueur UDP local préféré, soit l’interroger de nouveau lors de la création de vos nouveaux sockets. Pour plus d’informations sur la gestion de la suspension et de la reprise dans WinSock, consultez Suspension et reprise dans Winsock.

Changements du port multijoueur UDP local préféré

Le titre peut être à l’écoute des changements du port multijoueur UDP local préféré à l’aide de l’API XNetworkingRegisterPreferredLocalUdpMultiplayerPortChanged. Tout est mis en œuvre pour que le port multijoueur UDP local préféré ne change pas pendant l’exécution du titre. Toutefois, dans certains cas inévitables, le port change parce que les conditions du réseau externe de l’utilisateur changent et invalident les flux de socket existants. Le port est particulièrement susceptible de changer lorsque le niveau de connectivité réseau change, ou dans le cadre du cycle de suspension/reprise d’un titre. Lorsque le port multijoueur UDP local préféré change, les connexions entrantes supplémentaires provenant de futurs pairs pourraient être bloquées sur tout port préféré précédent. Cela pourrait ne pas causer d’échec au niveau de la couche socket. Toutefois, le titre pourrait éventuellement cesser de recevoir des paquets sur tout socket lié à un port préféré précédent. Les paquets envoyés aux pairs existants et reçus de ceux-ci pourraient continuer de fonctionner. Une notification de changement du port multijoueur UDP local préféré pourrait ne pas être fatale pour une session de jeu en cours. Lorsqu’une notification de changement survient, le titre doit migrer vers un nouveau socket lié au nouveau port préféré. Cette migration doit avoir lieu le plus tôt possible et sans interrompre le jeu en cours. Pour détecter une perte de connexion et pour retenter la connexion de socket, le titre doit toujours utiliser le port préféré le plus récent.

Tester les changements du port multijoueur UDP local préféré

Suivez les étapes ci-dessous pour changer le port multijoueur UDP local préféré.
  1. Pendant que votre jeu est en cours d’exécution, ouvrez le Guide XBOX. Accédez à l’application Paramètres.
  2. Dans l’onglet Général, sélectionnez Paramètres réseau.
  3. Sélectionnez Paramètres avancés, puis Sélection d’un autre port.
  4. Réglez la sélection du port sur Manuel. Pour sélectionner un port, utilisez le menu déroulant.
  5. La sélection du port prend effet immédiatement et entraîne l’envoi d’une notification correspondante à votre titre.
  6. Lorsque vous avez terminé vos tests, réglez de nouveau la sélection du port sur Automatique pour rétablir le comportement par défaut du port.
Lorsque vous êtes dans l’application Paramètres, votre titre est en mode restreint (constrained), mais continue de s’exécuter et reçoit immédiatement la notification de changement de port, même s’il n’est pas visible. Votre titre est suspendu si vous laissez l’application Paramètres ouverte pendant plus de 10 minutes sans revenir à votre titre.

Sécurité

Le socket lié au port multijoueur UDP local préféré se comporte comme n’importe quel autre socket. En particulier, le socket n’offre aucune sécurité supplémentaire. Le titre doit utiliser son propre protocole de communication sécurisé par-dessus le socket lié au port multijoueur UDP local préféré, comme le précisent les pratiques exemplaires en matière de sécurité des communications. Pour plus d’informations, consultez Vue d’ensemble de la sécurité des communications (rubrique sous NDA).

Pair à pair

Le port multijoueur UDP local préféré fournit le meilleur port connu à partir duquel un maillage pair à pair peut être établi. Il est configuré de la meilleure façon possible pour permettre les connexions entrantes à travers la couche NAT de l’utilisateur. Toutefois, il incombe au titre d’effectuer la traversée NAT, y compris ce qui suit.
  • Détection du type de NAT
  • Détection et échange de l’adresse IP publique et du port de l’appareil
  • Perforation (punching) et traversée NAT

Azure PlayFab Party

À l’interne, PlayFab Party utilise par défaut le port multijoueur UDP local préféré. Ce comportement est configurable au moyen de l’API PlayFab Party. À moins que le port de PlayFab Party ne soit modifié, le titre ne doit pas se lier directement au port multijoueur UDP local préféré.

Exemple d’utilisation

L’exemple suivant montre comment lier un socket à double pile au port multijoueur UDP local préféré. Par souci de concision, l’exemple utilise l’appel bloquant XNetworkingQueryPreferredLocalUdpMultiplayerPort et suppose que le titre a préalablement attendu que le réseau soit prêt et a déjà appelé WSAStartup.

Documentation de référence de l’API

Voir aussi

Référence de l’API du port multijoueur UDP local préféré (XNetworking) Windows Sockets 2 (Winsock) Vue d’ensemble de la sécurité des communications (rubrique sous NDA)
Last modified on October 6, 2026