Ce que nous avons capturé — et ce que nous n’avons pas capturé
Ces chiffres sont définitifs. Les serveurs officiels ont disparu, donc aucun nouveau trafic ne peut être capturé et plus rien sur cette page ne bougera.
Pour reconstruire Blades avant sa fermeture, nous devions enregistrer la façon dont le jeu parlait à ses serveurs. Nous avons fait l’effort de capturer le minimum — seulement Blades et ses serveurs Arena, jamais le reste du téléphone de qui que ce soit. Voici exactement comment, au grand jour.
316 contributeurs se sont inscrits pour aider à préserver le jeu. Ce qu’ils ont fait passer par nous, c’est tout ce qui survit.
Nous avons fait passer le minimum, exprès
Un VPN aurait pu envoyer tout le trafic d’un téléphone chez nous. Nous avons délibérément évité ça. Nous avons rétroconçu le protocole de matchmaking du jeu pour pouvoir autoriser précisément les serveurs utilisés par Blades — et laisser tout le reste (banque, messages, navigation, toutes les autres apps) sur la connexion normale, sans y toucher.
*.blades.bgs.services— connexion, personnages, matchmaking, CDN des assets- Les plages AWS GameLift des 14 régions où les matchs Arena pouvaient tourner
- Tout le reste sur l’appareil contournait entièrement le VPN
- Le HTTPS hors Blades qui passait quand même par ici était transmis tel quel — nous ne pouvions pas le déchiffrer, seulement
blades.bgs.services
Pourquoi l’Arena avait besoin de plus d’une IP
Le JcJ Arena tournait sur Amazon GameLift. Avant un match, le jeu testait 14 régions AWS et envoyait les latences ; GameLift plaçait ensuite le match dans la région la plus rapide ayant de la place, puis donnait au téléphone une IP serveur différente à chaque match. Il n’existait pas d’IP Arena fixe à autoriser.
Pour capturer l’Arena de manière fiable, nous avons donc fait passer les plages GameLift de ces 14 régions — et seulement celles-là. Nous avons confirmé la liste exacte des 14 de trois façons indépendantes (la table de points d’accès intégrée au client, ses cibles de mesure de latence et les requêtes de matchmaking en direct que nous avons capturées), ce qui nous permet d’être sûrs de ne pas avoir manqué une région ni débordé vers une région inutile.
La liste IP complète était écrite en clair dans chaque.conf que nous distribuions — ouvre-en un et lis chaque ligne.
La vraie latence Arena, mesurée par le jeu lui-même
Tout le monde débattait du lag en Arena. Voici la réponse, désormais permanente : les latences réellement mesurées par Blades vers chaque région, extraites des 28,100 requêtes de matchmaking capturées. Mesuré depuis l’emplacement de nos contributeurs (surtout Europe et Amérique du Nord), donc Meilleur est le plancher réaliste pour quelqu’un proche de cette région ; Typique est la médiane de tous nos échantillons.
| Région | Meilleur | Typique |
|---|---|---|
Europe (London) eu-west-2 | 10 ms | 71 ms |
Europe (Frankfurt) eu-central-1 | 12 ms | 67 ms |
US East (Ohio) us-east-2 | 14 ms | 161 ms |
South America (São Paulo) sa-east-1 | 16 ms | 264 ms |
Europe (Ireland) eu-west-1 | 18 ms | 79 ms |
Asia Pacific (Seoul) ap-northeast-2 | 20 ms | 286 ms |
US West (N. California) us-west-1 | 20 ms | 204 ms |
US West (Oregon) us-west-2 | 20 ms | 191 ms |
US East (N. Virginia) us-east-1 | 21 ms | 139 ms |
Canada (Central) ca-central-1 | 21 ms | 143 ms |
Asia Pacific (Mumbai) ap-south-1 | 22 ms | 188 ms |
Asia Pacific (Tokyo) ap-northeast-1 | 22 ms | 283 ms |
Asia Pacific (Sydney) ap-southeast-2 | 23 ms | 312 ms |
Asia Pacific (Singapore) ap-southeast-1 | 23 ms | 223 ms |
Quand l’Arena était-elle active ?
Déduit de la vitesse à laquelle le classement top 100 gagnait des coupes entre deux observations : cela reflète donc la population de joueurs plus large des derniers mois du jeu, pas seulement nous. Plus c’est sombre, plus il y avait de matchs. Les heures sont UTC. Nous ne pouvions échantillonner que lorsqu’un contributeur avait le classement ouvert, donc la couverture est irrégulière et limitée aux joueurs du top 100 : un vrai signal, pas un recensement complet.