Cosa abbiamo catturato, e cosa no
Questi dati sono definitivi. I server ufficiali non esistono più, quindi non si può catturare nuovo traffico e niente in questa pagina può più cambiare.
Per ricostruire Blades prima della chiusura abbiamo dovuto registrare come il gioco comunicava con i suoi server. Ci siamo impegnati a catturare il minimo: solo Blades e i server della sua arena, mai il resto del telefono di nessuno. Ecco esattamente come, alla luce del sole.
323 contributori si sono iscritti per aiutare a conservare il gioco. Ciò che hanno fatto passare da noi è tutto quello che sopravvive.
Abbiamo instradato il minimo, di proposito
Una VPN avrebbe potuto inviarci tutto il traffico di un telefono. Abbiamo scelto di non farlo. Abbiamo ricostruito il protocollo di matchmaking del gioco per poter autorizzare esattamente i server usati da Blades, e lasciare tutto il resto (banca, messaggi, navigazione, ogni altra app) sulla connessione normale, senza toccarlo.
*.blades.bgs.services— accesso, personaggi, matchmaking, la CDN degli asset- Gli intervalli AWS GameLift delle 14 regioni in cui potevano svolgersi le partite dell’arena
- Tutto il resto del dispositivo aggirava completamente la VPN
- L’HTTPS non di Blades che passava comunque da qui veniva inoltrato così com’era: non potevamo decifrarlo, solo
blades.bgs.services
Perché l’arena richiedeva più di un IP
Il PvP dell’arena girava su Amazon GameLift. Prima di una partita, il gioco faceva il ping di 14 regioni AWS e comunicava le latenze; GameLift collocava poi la partita nella regione più veloce con posti liberi e dava al telefono un IP del server diverso per ogni singola partita. Non c’era un IP fisso dell’arena da autorizzare.
Quindi, per catturare l’arena in modo affidabile, abbiamo instradato gli intervalli GameLift di quelle 14 regioni, e solo quelli. Abbiamo verificato l’elenco esatto delle 14 in tre modi indipendenti (la tabella di endpoint integrata nel client, i bersagli delle sue sonde di latenza e le richieste di matchmaking dal vivo che abbiamo catturato), quindi possiamo essere certi di non aver tralasciato una regione e di non aver invaso una che non ci serviva.
L’elenco completo degli IP era scritto in chiaro in ogni.conf che abbiamo distribuito: aprine uno e leggi ogni riga.
Il vero ping dell’arena, misurato dal gioco stesso
Tutti discutevano del lag nell’arena. Ecco la risposta, ora definitiva: le latenze reali misurate da Blades verso ciascuna regione, ricavate da 28,100 richieste di matchmaking catturate. Misurate da dove si trovavano i nostri contributori (soprattutto Europa e Nord America), quindi Migliore è il minimo realistico per chi si trova vicino a quella regione; Tipica è la mediana di tutti i nostri campioni.
| Regione | Migliore | Tipica |
|---|---|---|
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 |
Quando l’arena era affollata?
Dedotto dalla velocità con cui la classifica globale top 100 guadagnava coppe tra un’osservazione e l’altra, quindi riflette la popolazione di giocatori più ampia negli ultimi mesi del gioco, non solo noi. Più scuro = più partite. Gli orari sono in UTC. Potevamo campionare solo quando un contributore aveva la classifica aperta, quindi la copertura è irregolare e limitata ai giocatori della top 100: un segnale reale, non un censimento completo.