Passer au contenu principal

Utiliser les balises de qualité de service (QoS) pour mesurer la latence des joueurs vers Azure

Vous pouvez déployer des serveurs multijoueurs PlayFab dans plus d’une douzaine de régions Azure. Il y a deux raisons de le faire :
  1. Les régions supplémentaires assurent la redondance. Si une région Azure tombe en panne, les joueurs peuvent accéder aux serveurs d’autres régions.
  2. Les régions supplémentaires permettent aux joueurs d’accéder à des serveurs « proches » qui offrent une connectivité à faible latence.
Lorsque vous appelez RequestMultiplayerServer, vous spécifiez une liste classée de régions Azure que PlayFab utilise pour traiter la demande. PlayFab tente de traiter la demande avec la région classée en première position, mais s’il n’y a pas de serveurs de secours dans cette région, ou si la région présente un autre problème, une région moins optimale située plus bas dans la liste est essayée. Dans la mesure du possible, utilisez les données de latence des joueurs pour établir le classement des régions Azure utilisées lors de la demande d’un serveur multijoueur. PlayFab fournit des services et des outils pour vous aider dans cette tâche.

Balises de qualité de service

PlayFab exploite des balises dans chaque région Azure utilisée par les serveurs multijoueurs PlayFab. Ces balises retournent le trafic UDP et peuvent être utilisées pour mesurer la latence avec le transport UDP. L’utilisation d’UDP est importante, car la plupart des jeux multijoueurs utilisent le transport UDP pour leur trafic de jeu le plus critique en termes de performances. Les fournisseurs d’accès à Internet et d’autres éléments de l’écosystème Internet peuvent offrir des performances différentes pour les flux UDP, TCP et ICMP. Voici le flux type d’utilisation de ces balises dans le contexte d’un appareil de joueur :
  1. Connectez le joueur à PlayFab. Cela se fait généralement avec LoginWithCustomID ou une autre API de connexion.
  2. Appelez ListQoSServersForTitle. Cet appel fournit les noms d’hôte des balises QoS de PlayFab. Dans une implémentation type, cette procédure peut avoir lieu sur la page Menu multijoueur du jeu.
  3. Créez un socket UDP.
  4. Envoyez un seul datagramme UDP au port 3075 du serveur QoS. Le contenu du message doit commencer par 0xFFFF (1111 1111 1111 1111).
  5. Le serveur répond avec un seul datagramme dont les 2 premiers octets du contenu sont « inversés » en 0x0000 (0000 0000 0000 0000). Le reste du contenu du datagramme est copié à partir du ping initial.
  6. Mesurez le temps écoulé entre l’envoi du message UDP et la réception d’une réponse.

Utiliser le SDK de qualité de service

Le SDK C# et le SDK multiplateforme (CPP) de PlayFab fournissent une implémentation du code de ping QoS. Vous pouvez compiler un SDK et l’utiliser comme bibliothèque d’assistance dans vos jeux PC, référencer le package NuGet C#, ou utiliser le code comme exemple pour d’autres plateformes. Chaque API retourne un QosResult qui contient une liste triée de régions ainsi que le temps de ping moyen vers chaque région.

C#

Des API QoS sont disponibles dans le SDK C#. Un exemple d’implémentation, WindowsRunnerCSharpClient, est disponible dans le référentiel gsdkSamples. Le code se trouve dans PlayFabQosApi.cs. Paramètres :
  • timeoutMs - Le délai d’expiration (en millisecondes) appliqué à chaque tentative de ping (valeur par défaut : 250 ms).
  • pingsPerRegion - Le nombre de tentatives de ping à effectuer pour chaque région (valeur par défaut : 10). Augmenter ce nombre allonge le temps d’exécution, mais réduit le risque de résultats inexacts.
  • degreeOfParallelism - Le nombre maximal de pings à effectuer en parallèle (valeur par défaut : 4). Augmenter ce nombre réduit le temps d’exécution, mais la contention réseau peut entraîner des résultats inexacts si ce nombre est trop élevé.

C++

Deux API QoS sont disponibles dans le SDK multiplateforme (CPP) de PlayFab. Le code se trouve dans PlayFabQosApi.cpp. Paramètres :
  • numThreads - Le nombre maximal de pings à effectuer en parallèle. Augmenter ce nombre réduit le temps d’exécution, mais la contention réseau peut entraîner des résultats inexacts si ce nombre est trop élevé.
  • timeoutMs - Le délai d’expiration (en millisecondes) appliqué à chaque tentative de ping (valeur par défaut : 250 ms).
Dernière modification le 19 octobre 2026