Terminologie de la limitation précise du débit
Utilisation équitable
XBOX estime que chaque utilisateur doit bénéficier de la même expérience de haute qualité, quel que soit le jeu (ou l’application) auquel il joue. La limitation précise du débit (FGRL) résout le scénario suivant : Le développeur A vient de publier un titre qui suit toutes les pratiques exemplaires des services XBOX afin d’utiliser les services de manière optimale, tandis que le développeur B vient également de publier un titre, qui comporte toutefois un bogue inconnu. Ce bogue amène le titre et chaque utilisateur à inonder le service de présence de requêtes, ce qui le soumet à une charge importante. Le service ralentit puis finit par s’arrêter, dégradant l’expérience des utilisateurs du développeur A alors que c’est le bogue du développeur B qui est à l’origine du problème. Si la FGRL avait été mise en œuvre, le service aurait pu cesser de recevoir les requêtes du titre défaillant, ce qui lui aurait permis de servir au titre du développeur A sa part équitable des ressources.Granularité titre et utilisateur
Le titre et l’utilisateur ont été choisis comme clé pour garantir une utilisation équitable des ressources XBOX. Le suivi du seul utilisateur créerait un scénario dans lequel l’expérience utilisateur dépendrait de l’intégration de chaque titre. Par exemple, la plupart des titres utilisent déjà le service People; pour les besoins de cet exemple, supposons que la limitation précise du débit soit configurée sur le service People pour n’autoriser que 100 requêtes en 5 minutes. Si un utilisateur jouait à un jeu effectuant 100 requêtes en 1 minute, la limite serait dépassée et l’utilisateur ne pourrait plus envoyer de requêtes au service People. Imaginons qu’au cours de la même période, l’utilisateur revienne ensuite à l’écran d’accueil et clique sur sa liste d’amis : comme il aurait déjà dépassé la limite, l’appel à la liste d’amis échouerait jusqu’à la fin de l’intervalle de 5 minutes, alors que l’écran d’accueil n’est pas responsable de la limitation de l’utilisateur. À l’inverse, une limitation basée uniquement sur le titre produirait un résultat tout aussi injuste. Définir une limite par titre ne tiendrait pas compte de la popularité des titres, et les requêtes seraient simplement traitées dans l’ordre d’arrivée jusqu’à ce qu’une limite soit atteinte. L’association utilisateur-titre garantit qu’aucun titre n’utilise plus de ressources que ce qui est approprié compte tenu de son nombre d’utilisateurs actifs, tout en offrant à chaque utilisateur une part constante des ressources.
- Si la requête est en dessous de la limite, elle est traitée normalement.
- Si la requête atteint ou dépasse la limite, le service l’abandonne et renvoie à la place une réponse 429.
Limites de rafale et soutenues
Traditionnellement, la limitation du débit consiste en une limite par point de terminaison, suivie sur une période donnée. Cette période représente la durée pendant laquelle le nombre de requêtes d’une entité est suivi. À la fin de la période, le compteur de l’entité est remis à 0 pour recommencer le suivi. Cette approche fonctionne pour la plupart des API; cependant, elle n’était pas suffisamment robuste pour les jeux et les applications qui appellent les services XBOX. La solution ci-dessus suppose que les appels sont effectués de manière constante, régulière et prévisible. Dans le cas des services XBOX, selon le service et le titre demandeur, les modèles d’appel sont radicalement différents. Choisir une seule limite dans ce cas obligerait à faire des compromis aux deux extrémités du spectre des modèles d’appel. La solution des services XBOX utilise deux périodes et deux limites. La plus courte est appelée période de rafale (Burst), tandis que la plus longue est appelée période soutenue (Sustain). La période de rafale de la FGRL est toujours de 15 secondes, tandis que la période soutenue est toujours de 300 secondes (5 minutes). Une période soutenue de 5 minutes comprend donc 20 périodes de rafale. Les limites de rafale et soutenues sont suivies simultanément et comptent donc les requêtes en même temps. La limite de rafale et la limite soutenue sont toutes deux définies sur le service, ce qui signifie que chaque service possède ses propres compteurs de rafale et soutenu. Pour vous aider à comprendre comment ces deux limites fonctionnent ensemble, le tableau ci-dessous présente un utilisateur jouant à un titre qui envoie un certain nombre de requêtes à un service ayant mis en œuvre la FGRL. Dans ce cas, la limite de rafale est de 30 requêtes en 15 secondes et la limite soutenue de 100 requêtes en 5 minutes.
Le tableau montre qu’au cours des 15 premières secondes, l’utilisateur déclenche la limite de rafale en effectuant 35 requêtes.
Ces 5 requêtes supplémentaires sont abandonnées et 5 réponses 429 sont envoyées.
Bien qu’elles soient limitées, ces 5 requêtes comptent toujours dans la limite soutenue.
Dès que l’une ou l’autre limite est déclenchée, aucune requête n’est acceptée, comme le montre le déclenchement des deux limites à 45 secondes, puis à nouveau lorsque seulement 4 requêtes sont effectuées à 285 secondes.
Objet de réponse HTTP 429
Lorsque le compteur associé à l’utilisateur et au titre atteint ou dépasse la limite de rafale ou la limite soutenue, le service ne traite pas la requête et renvoie à la place une réponse HTTP 429. Avec XSAPI, cela équivaut à un HRESULT de 0x801901AD. Le code HTTP 429, qui signifie « trop de requêtes », est accompagné d’un en-tête contenant une valeur « réessayer après X secondes ». Un objet de réponse 429 de la FGRL contient un en-tête « retry after » qui indique combien de temps les entités appelantes doivent attendre avant de réessayer. Les développeurs qui utilisent XSAPI n’ont pas à s’en soucier, car XSAPI respecte et gère l’en-tête Retry-After. La réponse proprement dite contient les champs suivants :Limites mises en œuvre
Les services suivants ont mis en œuvre des limites FGRL, appliquées depuis mai 2016. Ces limites sont les mêmes pour tous les sandboxes et tous les titres. Tout titre publié au moyen de XBOX Developer Platform ou Partner Center et commercialisé avant mai 2016 est considéré comme hérité et, à ce titre, exempté.
Le tableau ci-dessus représente la liste actuelle des services sélectionnés pour la FGRL.
Cette liste n’est pas définitive, car de nouveaux services et des services existants peuvent y être ajoutés.
Lorsqu’un service sera ajouté, ce tableau sera mis à jour et une annonce sera faite.
Les limites du tableau peuvent être modifiées.
À mesure que les services changent et évoluent, les limites évolueront également; vous en serez toutefois informé et les exemptions héritées nécessaires seront accordées.
Correspondance des services et effets de la limitation du débit sur les titres
REMARQUE : la correspondance des API la plus récente est régulièrement mise à jour et disponible dans Live Trace Analyzer API Mapping.