Skip to main content
Utilisez cette rubrique pour comprendre comment utiliser les API de port multijoueur UDP (User Datagram Protocol) local préféré afin d’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 connu, enregistré publiquement, destiné au trafic réseau multijoueur. Les titres Microsoft Game Development Kit (GDK) ne font pas exception et peuvent utiliser les API 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 ultérieure de liaison de socket, par opposition au port public que les appareils distants peuvent 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 spécifiquement les flux réseau multijoueurs en temps réel des titres. Historiquement, le port était limité à UDP 3074. Cependant, ces dernières années, une logique de repli a été introduite pour accroître la fiabilité de ce port. De plus, les utilisateurs peuvent configurer manuellement le port pour qu’il fonctionne avec leur propre configuration réseau. C’est pourquoi il n’est plus sûr de coder en dur UDP 3074 dans un titre Microsoft Game Development Kit (GDK). Les titres 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. Un titre Microsoft Game Development Kit (GDK) peut appeler l’une d’entre elles (ou une combinaison) en fonction de ses besoins et cas d’usage spécifiques. Nous recommandons vivement à tous les titres Microsoft Game Development Kit (GDK) d’utiliser le port préféré pour leur trafic de jeu principal. Ce port est optimisé à la fois pour les topologies réseau pair à pair et pour les topologies réseau client/serveur. La plateforme Microsoft Game Development Kit (GDK) garantit que ce port spécifique est celui qui a le plus de chances de fonctionner dans l’environnement réseau particulier de chaque utilisateur. L’utilisation de ce port spécifique permet de tirer pleinement parti des flux de support client et de diagnostic de la plateforme, améliore la compatibilité standardisée avec la traduction d’adresses réseau (NAT), fournit une fonctionnalité standardisée pour les appareils certifiés UPnP™ et identifie les paquets comme 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 réseau pair à pair. C’est le seul port qui autorise les paquets UDP entrants à traverser le pare-feu sans traversée du pare-feu (firewall punching). Les titres qui reposent sur des topologies réseau pair à pair dans le Microsoft Game Development Kit (GDK) doivent néanmoins 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 s’y substitue pas. Les titres qui utilisent des topologies réseau client/serveur bénéficient également de l’utilisation de ce port. La résolution des problèmes, UPnP™ et l’identification des paquets restent pertinentes 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 universitaires. 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 à 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é puisse ê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 à 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/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 leur retour.

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 via RegisterAppStateChangeNotification. Lors de la reprise, vous devez supposer que le port multijoueur UDP local préféré a changé et soit écouter les modifications de ce port, soit l’interroger à nouveau lors de la création de vos nouveaux sockets. Pour plus d’informations sur la gestion de la suspension et de la reprise avec WinSock, consultez Suspension et reprise dans Winsock.

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

Le titre peut écouter les modifications 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. Cependant, il existe des cas inévitables où le port change, parce que les conditions réseau externes de l’utilisateur changent et invalident tous 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 d’un cycle de suspension/reprise du titre. Lorsque le port multijoueur UDP local préféré change, les connexions entrantes supplémentaires provenant de futurs pairs peuvent être bloquées sur tout port préféré précédent. Cela peut ne pas provoquer d’échec au niveau de la couche socket. Toutefois, le titre peut finir par cesser de recevoir des paquets sur tout socket lié à un port préféré précédent. Les paquets envoyés vers et depuis des pairs existants peuvent continuer à fonctionner. Une notification de modification du port multijoueur UDP local préféré n’est pas nécessairement fatale pour une session de jeu en cours. Lorsqu’une notification de modification se produit, 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 la partie en cours. Pour détecter une perte de connexion et retenter la connexion du socket, le titre doit toujours utiliser le port préféré le plus récent.

Test des modifications du port multijoueur UDP local préféré

Procédez comme suit pour modifier le port multijoueur UDP local préféré.
  1. Pendant l’exécution de votre jeu, ouvrez le Guide XBOX. Accédez à l’application Paramètres.
  2. Sous 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. Définissez 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 envoie une notification correspondante à votre titre.
  6. Une fois vos tests terminés, redéfinissez 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 il continue de s’exécuter et reçoit immédiatement la notification de modification du port, même s’il n’est pas visible. Votre titre est suspendu si vous laissez l’application Paramètres ouverte 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, il 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éconisent les bonnes pratiques 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é est le meilleur port connu à partir duquel un maillage pair à pair peut être construit. Il est configuré de la meilleure façon possible pour autoriser les connexions entrantes à travers la couche NAT de l’utilisateur. Cependant, il incombe au titre d’effectuer la traversée NAT, notamment les opérations suivantes.
  • Détection du type de NAT
  • Détection et échange de l’adresse IP publique et du port de l’appareil
  • Perçage (punching) et traversée NAT

Azure PlayFab Party

En interne, PlayFab Party utilise par défaut le port multijoueur UDP local préféré. Ce comportement est configurable via 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