Exigences de PlayFab Party en matière d’utilisation des ports, de pare-feu et de taille des paquets
Cette rubrique fournit des détails sur les exigences de PlayFab Party en matière d’utilisation des ports, de pare-feu et de taille des paquets, nécessaires pour activer la communication de chat et de données.Modèles de communication
PlayFab Party utilise deux modèles de communication :- La communication HTTPS, initiée par l’appelant de l’API vers plusieurs services web cloud, notamment playfabapi.com.
- La communication sécurisée basée sur des sockets UDP avec les serveurs de relais cloud transparents et avec d’autres appareils pairs (si cela est pris en charge).
PartyRegionsChangedStateChange initial signalent PartyStateChangeResult::InternetConnectivityError.
En cas de problème de requête vers les services web, d’autres opérations PlayFab et de plateforme nécessaires en dehors de Party, telles que les fonctions de connexion des utilisateurs, échoueraient probablement aussi. Ces échecs sont souvent causés par des restrictions de pare-feu local ou par des exigences de proxy pour les connexions HTTPS. La plupart des problèmes peuvent être résolus en activant la communication HTTPS sortante directe vers les services web cloud depuis l’appareil ou le réseau local.
Noms de domaine HTTPS
Microsoft PlayFab Party établit des connexions UDP et HTTPS vers plusieurs services cloud. Pour garantir un fonctionnement correct, les environnements qui filtrent le trafic HTTPS en fonction du nom de domaine doivent s’assurer que les noms ou modèles de noms suivants sont accessibles : Connectivité HTTPS :- *.playfabapi.com
- *.speech.microsoft.com
- api.cognitive.microsofttranslator.com
MTU et taille des paquets
PlayFab Party effectue automatiquement la fragmentation et le réassemblage pour faire tenir les messages d’application volumineux dans les limites de taille de paquet de l’environnement. Certains environnements réseau peuvent néanmoins provoquer des échecs de communication malgré cette fonctionnalité. PlayFab Party s’attend actuellement à ce que les environnements prennent en charge une unité de transmission maximale (MTU) d’au moins 1 419 octets pour éviter de mauvaises performances ou d’éventuels échecs de connectivité. Cette taille de MTU est prise en charge dans les environnements classiques. Les réseaux privés virtuels (VPN), le tunneling IPv4/IPv6 ou une configuration administrative explicite peuvent réduire la taille de la MTU dans un sens ou dans les deux sens du chemin réseau entre le client Party, le service ou d’autres clients. Si la MTU prise en charge de bout en bout dans un environnement donné est insuffisante, l’opérationPartyManager::ConnectToNetwork peut échouer avec PartyStateChangeResult::InternetConnectivityError. La connectivité peut aussi réussir, mais l’appareil peut alors subir une latence inutile, des pertes de paquets ou des déconnexions inattendues.
Certaines plateformes fournissent aux utilisateurs finaux, aux développeurs ou aux fournisseurs d’accès à Internet des outils permettant de diagnostiquer la configuration de la MTU dans leur environnement ; ces outils doivent être utilisés dans la mesure du possible.
Utilisation des ports UDP de l’appareil local
Par défaut, sur la plupart des plateformes, la bibliothèque PlayFab Party lie son socket UDP à un port local disponible attribué dynamiquement par le système d’exploitation. Microsoft Game Core fait exception : PlayFab Party s’y lie par défaut au « port multijoueur UDP local préféré » de cette plateforme. Les titres peuvent modifier ce comportement pour se lier à un numéro de port local spécifique, ou à un port disponible sélectionné par le système d’exploitation autre que le « port multijoueur UDP local préféré » de Microsoft Game Core, en définissant l’optionPartyOption::LocalUdpSocketBindAddress avant d’appeler PartyManager::Initialize(). Si le port demandé est déjà utilisé dans votre titre ou par une autre application sur l’appareil, soit PartyManager::Initialize() signale immédiatement une erreur, soit le PartyRegionsChangedStateChange initial signale une erreur PartyStateChangeResult::FailedToBindToLocalUdpSocket et les opérations asynchrones de création de réseau ou de connexion échouent.
Il est recommandé aux titres d’utiliser le comportement de sélection de port local par défaut afin d’obtenir une compatibilité maximale sans configuration, sauf si l’utilisateur final le demande pour une raison propre à son environnement. Des exigences supplémentaires propres à la plateforme peuvent s’appliquer si votre titre utilise des valeurs autres que celles par défaut. Consultez la documentation de chaque plateforme pour obtenir des conseils sur l’utilisation des ports.
La communication PlayFab Party exige toujours que les paquets initiés en sortie et leurs réponses soient autorisés depuis ce port UDP local sélectionné vers les destinations distantes décrites dans la section suivante. Les administrateurs réseau doivent suivre les bonnes pratiques standard d’Internet en matière de pare-feu et de traduction d’adresses réseau (NAT), comme celles de la RFC 4787 - « Network Address Translation (NAT) Behavioral Requirements for Unicast UDP », pour une compatibilité maximale. Ces bonnes pratiques sont particulièrement importantes pour les titres qui utilisent des connexions pair à pair directes pour un réseau Party, car les environnements offrant une prise en charge minimale peuvent permettre la connexion au réseau tout en empêchant l’établissement de cette communication directe d’un appareil à un autre.
Adresses IP et ports UDP distants
Microsoft PlayFab Party fournit des services mis à l’échelle dynamiquement dans plusieurs régions afin d’offrir la meilleure latence aux utilisateurs. Cela signifie qu’il n’existe pas de nom d’hôte, d’adresse IP ou de port de destination distant permanent auquel les administrateurs réseau souhaitant imposer des contraintes de communication strictes pourraient se référer. Microsoft fournit chaque semaine des mises à jour d’une liste de plages d’adresses IP pour Azure, disponible en téléchargement. Cette liste peut être utile s’il est possible de maintenir une stratégie synchronisée en continu pour restreindre le trafic réseau local. Dans la plupart des cas, la maintenance continue de cette liste est difficile et sujette à des échecs de connectivité subtils. En outre, pour les connexions pair à pair directes au sein d’un réseau Party, les adresses IP des clients distants doivent également être connues et autorisées pour la connectivité. Pour ces raisons, nous recommandons que les pare-feu ne restreignent pas la connectivité aux adresses IP distantes. La plage de ports distants prise en charge susceptible d’être utilisée par PlayFab Party peut inclure tous les ports en dehors de la plage réservée par l’IANA (Internet Assigned Numbers Authority), soit 0-1023. Actuellement, seuls des numéros de port compris entre 30000 et 65535 sont attribués aux relais cloud transparents, mais Microsoft se réserve le droit de modifier ce comportement à l’avenir. À titre de bonne pratique, la plage de ports 1024-65535 doit être utilisée. Cela est particulièrement important pour les titres qui utilisent des connexions pair à pair directes pour un réseau Party, car les implémentations NAT attribuent généralement des ports dans cette plage. Le blocage de ports distants autres que ceux de la plage recommandée complète peut également empêcher la communication directe. Pour activer la connectivité UDP, les environnements qui filtrent le trafic UDP en fonction du nom de domaine doivent s’assurer que les noms ou modèles de noms suivants sont accessibles :- *.cloudapp.azure.com