Erro de matchmaking ou de atribuição de região Wrong region assignment (matchmaking / GeoDNS)
ID da causa in-region-match · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Infraestrutura de rede (Equipe de infraestrutura), Externo (Externo)
Quando o jogador é mandado para um servidor de uma região distante, mesmo havendo uma região próxima, só o ping dele fica sempre alto, ainda que a conexão esteja boa.
Por quê Erro nos dados de GeoIP, VPN, party inteira atribuída pela média de ping dos membros, regra que amplia a busca para regiões distantes quando faltam jogadores, atribuição pela localização do resolvedor DNS → Efeito Conexão a um servidor em uma região do outro lado do oceano, mesmo havendo uma região próxima → Na tela Em jogos com servidores em várias regiões, só você (ou só a sua party) tem ping sempre alto, com input lag, rubber banding e skills que não saem
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Infraestrutura de rede (Equipe de infraestrutura), Externo (Externo)
O que fazer (Equipe de desenvolvimento)
Servidor: atribuir pela latência que o cliente mediu para cada região no lugar do GeoIP, colocar um teto de ping na regra que amplia para regiões distantes, considerar o ping mais alto da party além da média, registrar em log a região atribuída e o ping no momento. Cliente: medir o ping de cada região por UDP e enviar junto com o pedido de matchmaking, mostrar na tela a região conectada e o ping, oferecer a opção de escolher a região manualmente.
O que fazer (Equipe de infraestrutura)
Se a região é escolhida por DNS, verificar se o DNS autoritativo suporta EDNS Client Subnet (se o resolvedor do jogador não enviar, a atribuição segue a localização do resolvedor), atualizar o banco de dados de GeoIP periodicamente, anexar país e ASN do GeoIP aos logs de conexão dos servidores de cada região para achar países e operadoras que vão para regiões distantes.
O que fazer (Externo)
Orientar os jogadores a desligar VPN e redutor de ping e conectar de novo, orientar quem usa DNS corporativo ou do exterior a trocar para o DNS da operadora, pedir ao provedor de GeoIP a correção de localizações erradas.
Números de referência
Um jogador de Seul atribuído à região Oeste dos EUA no lugar de Tóquio vê o ping subir de cerca de 30 ms para cerca de 130 ms. O GeoIP acerta cerca de 99,8% no nível de país, mas no nível de cidade, mesmo nos EUA, só cerca de 66% ficam dentro de 50 km, e com VPN aparece a localização do servidor VPN no lugar da do jogador.
No gráfico
Alto só em alguns · RTT (ping) por jogador, distribuição das regiões atribuídas
Onde olhar
Anexar país e ASN do GeoIP aos IPs de clientes nos registros de conexão dos servidores de cada região (logs de acesso do load balancer, VPC Flow Logs) e contar para qual região cada país e operadora se conectou. Para um único jogador, comparar a região em que ele realmente se conectou com o ping até a região próxima (medido pelo jogador ou com mtr do servidor dessa região para o IP dele)
Confirma se
Jogadores e países com RTT alto estão conectados a uma região distante, havendo uma próxima, e o ping medido até a região próxima é baixo
Descarta se
Atribuído corretamente à região próxima e ainda assim com ping alto: aponta para roteamento com desvio ou para a conexão ou o Wi-Fi desse jogador
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
A escolha de região por DNS (DNS por geolocalização ou por latência) estima a localização do jogador pelo endereço do resolvedor DNS que ele usa. Se o resolvedor não suporta EDNS Client Subnet, que repassa parte do endereço do jogador, quem usa DNS corporativo ou um DNS distante é atribuído pela localização do resolvedor. O sistema de matchmaking também pode avaliar a party pela média de ping dos membros ou, depois de muita espera, ampliar o critério de ping e mandar o grupo para uma região distante. No AWS GameLift Servers, o critério padrão de ping da party também é a média, e a documentação dá como exemplo uma configuração que amplia o teto de ping de 50 ms para 100 ms e depois 200 ms. Para quem usa VPN, a latência extra do servidor intermediário (“Tráfego via VPN ou redutor de ping”) pode se somar à atribuição a uma região distante; para separar as duas coisas, veja se a região atribuída muda ao desligar a VPN e conectar de novo. Quando não existe região próxima e a conexão vai para uma distante, o assunto é tratado em “Atraso de propagação (distância física)”.
Fontes
RFC 7871: Client Subnet in DNS QueriesIETF DNS que responde de acordo com a localização estima a posição pelo endereço do resolvedor que enviou a consulta, e quem usa um resolvedor central distante recebe respostas inadequadas. O EDNS Client Subnet (opcional) repassa parte do endereço do usuário
How Amazon Route 53 uses EDNS0 to estimate the location of a userAWS Se o resolvedor não suporta edns-client-subnet, a localização do usuário é estimada pelo endereço do resolvedor, e a resposta segue a localização dele (vale para roteamento por geolocalização e por latência)
Geolocation accuracyMaxMind Cerca de 99,8% no nível de país, cerca de 66% no nível de cidade nos EUA (dentro de 50 km); com VPN, aparece a localização do servidor VPN no lugar da do usuário final; IPs de rede móvel são usados em áreas amplas e não dão localização precisa; o banco de dados precisa de atualização contínua; aceita pedidos de correção
FlexMatch rule typesAWS A regra de latência (maxLatency) olha a latência dos jogadores em cada local, a party usa por padrão a média dos membros (partyAggregation avg), e a fila pode alocar em regiões que não atendem à regra de latência
Create a player latency policyAWS Aloca no local com a menor latência média entre todos os jogadores, mas jogadores com latência extrema também são alocados; exemplo de política que amplia o teto de ping de 50 ms para 100 ms e depois 200 ms
Amazon GameLift Servers UDP ping beaconsAWS O cliente do jogo mede a latência com endpoints UDP presentes em cada local de hospedagem e usa o resultado na alocação e no matchmaking; é mais próximo do tráfego real do jogo que o ping ICMP
Azure network round-trip latency statisticsMicrosoft Azure Mediana medida de ida e volta a partir de Seul (Korea Central): Tóquio (Japan East) 29 ms, Oeste dos EUA 124–136 ms
Flow log recordsAWS srcaddr em registros de VPC Flow Logs: no tráfego de entrada, endereço IP de quem enviou
Veja também
Mesma camada: L13 Arquitetura e operação de servidores