Errores de matchmaking y asignación de región Wrong region assignment (matchmaking / GeoDNS)
ID de la causa in-region-match · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo), Infraestructura de red (Equipo de infraestructura), Externo (Externo)
Si a un jugador se le asigna un servidor de una región lejana cuando hay una cercana, tiene siempre el ping alto aunque su conexión esté bien.
Por qué Datos de GeoIP erróneos, VPN, asignación de todo el grupo según el ping medio de sus miembros, reglas que amplían la búsqueda a regiones lejanas cuando faltan jugadores, asignación según la ubicación del resolver DNS → Efecto Se conecta a un servidor de una región al otro lado del océano aunque haya una región cercana → En pantalla En un juego con servidores en varias regiones, solo tú (o solo tu grupo) tienes siempre el ping alto, con input lag, rubber banding y habilidades que no salen
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo), Infraestructura de red (Equipo de infraestructura), Externo (Externo)
Tareas (Equipo de desarrollo)
Servidor: asignar según el ping por región que mide el cliente, sin depender de GeoIP; poner un tope de ping a las reglas que amplían la búsqueda a regiones lejanas; en los grupos, mirar además del promedio el ping del miembro que lo tiene más alto; registrar en el log la región asignada y el ping en ese momento. Cliente: medir por UDP el ping a cada región y enviarlo con la solicitud de matchmaking, mostrar en pantalla la región conectada y el ping, ofrecer la opción de elegir la región a mano.
Tareas (Equipo de infraestructura)
Si la región se elige por DNS, comprobar que el DNS autoritativo admite EDNS Client Subnet (si el resolver que usa el jugador no lo envía, se asigna según la ubicación del resolver), actualizar con regularidad la base de datos de GeoIP, añadir el país y el ASN de GeoIP a los logs de conexión de los servidores de cada región para encontrar los países e ISP que acaban en regiones lejanas.
Tareas (Externo)
Indicar a los jugadores que desactiven la VPN o el acelerador de juegos y vuelvan a conectarse, indicar a quienes usan el DNS de su empresa o un DNS extranjero que prueben con el DNS de su ISP, pedir al proveedor de GeoIP que corrija las ubicaciones erróneas.
Cifras de referencia
Si a un jugador de Seúl le toca la región de la costa oeste de EE. UU. y no la de Tokio, el ping pasa de unos 30 ms a unos 130 ms. GeoIP acierta el país en torno al 99.8% de las veces, pero a nivel de ciudad, incluso en EE. UU., solo alrededor del 66% de los casos cae dentro de un radio de 50 km, y con una VPN lo que aparece es la ubicación del servidor VPN.
En el gráfico
Alto solo en algunos · RTT (ping) por jugador, distribución de las regiones asignadas
Dónde mirar
Añadir el país y el ASN de GeoIP a las IP de cliente de los registros de conexión de los servidores de cada región (logs de acceso del balanceador de carga, VPC Flow Logs) y contar a qué región se conectó cada país e ISP. Para un solo jugador, comparar la región a la que se conectó realmente con el ping medido hasta la región cercana (medido por el jugador, o con mtr desde un servidor de esa región hacia su IP)
Se confirma si
Los jugadores o países con RTT alto están conectados a una región lejana teniendo una cercana, y el ping medido hasta la región cercana es bajo
Se descarta si
Si se le asignó bien la región cercana y aun así el ping es alto, apunta a “Enrutamiento con rodeos” o a la conexión o el Wi-Fi de ese jugador
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Para saber más
Cuando la región se elige por DNS (DNS por geolocalización o por latencia), la ubicación se estima a partir de la dirección del resolver DNS que usa el jugador, sin ver la del propio jugador. Si el resolver no admite EDNS Client Subnet, que transmite parte de la dirección del jugador, a quienes usan el DNS de su empresa o un DNS lejano se les asigna según dónde está el resolver. Los sistemas de matchmaking también juzgan a veces a un grupo por el ping medio de sus miembros o, tras una espera larga, amplían el criterio de ping y lo asignan a una región lejana. En AWS GameLift Servers el criterio predeterminado para el ping del grupo también es el promedio, y su configuración de ejemplo amplía el tope de ping de 50 ms a 100 ms y luego a 200 ms. En un jugador con la VPN activada pueden sumarse la latencia añadida por el servidor intermedio (“Paso por una VPN o un acelerador de juegos”) y la asignación a una región lejana; para distinguirlas, se comprueba si la región asignada cambia al desactivar la VPN y volver a conectarse. El caso en que no hay ninguna región cercana y hay que conectarse a una lejana se trata en “Retardo de propagación (distancia física)”.
Fuentes
RFC 7871: Client Subnet in DNS QueriesIETF Un DNS que responde distinto según la ubicación la estima a partir de la dirección del resolver que envía la consulta, y si el jugador usa un resolver centralizado lejos de él, la respuesta no es la adecuada. EDNS Client Subnet (función opcional) transmite parte de la dirección del jugador
How Amazon Route 53 uses EDNS0 to estimate the location of a userAWS Si el resolver no admite edns-client-subnet, la ubicación del jugador se estima por la dirección del resolver y se responde según dónde está el resolver (igual en el enrutamiento por geolocalización y por latencia)
Geolocation accuracyMaxMind País: alrededor del 99.8%; ciudad en EE. UU. (dentro de 50 km): alrededor del 66%; con VPN aparece la ubicación del servidor VPN y no la del usuario final; las IP de redes móviles se usan en zonas amplias y no permiten una ubicación precisa; la base de datos hay que actualizarla continuamente; se pueden pedir correcciones
FlexMatch rule typesAWS La regla de latencia (maxLatency) mira la latencia del jugador en cada ubicación; para los grupos usa por defecto el promedio de sus miembros (partyAggregation avg); la cola también puede colocar partidas en regiones que no cumplen la regla de latencia
Create a player latency policyAWS Coloca la partida en la ubicación con la latencia media más baja de todos los jugadores, pero también se colocan jugadores con latencias extremas; ejemplo de política que amplía el tope de ping de 50 ms a 100 ms y luego a 200 ms
Amazon GameLift Servers UDP ping beaconsAWS El cliente del juego mide la latencia con los endpoints UDP que hay en cada ubicación de hosting y la usa para la colocación y el matchmaking; se parece más al tráfico real del juego que un ping ICMP
Azure network round-trip latency statisticsMicrosoft Azure Mediana de ida y vuelta medida desde Seúl (Korea Central): Tokio (Japan East) 29 ms, costa oeste de EE. UU. 124–136 ms
Flow log recordsAWS srcaddr de un registro de VPC Flow Logs: en el tráfico entrante, dirección IP del emisor
Ver también
Misma capa: L13 Arquitectura y operación de servidores