한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Libro blanco del lag en juegos › Diseño del netcode

Protocolo con muchas idas y vueltas secuenciales (chatty) Chatty protocol / sequential round trips

ID de la causa sy-chatty · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)

Abrir la ficha interactiva con gráficos y simulaciones →

Si una sola acción necesita varias idas y vueltas al servidor en secuencia, el ping se multiplica por ese número.

Por qué Abrir la tienda → pedir la lista → consultar el precio → comprar → actualizar el inventario, cada paso como una solicitud aparte → Efecto La siguiente solicitud solo se envía tras recibir la respuesta de la anterior → En pantalla Con 150 ms de ping, una compra tarda casi 1 segundo. Las cargas son inusualmente largas

Síntomas
Input lag, No conecta / carga infinita
Factores
Latencia
A quién afecta
Solo una función, Solo yo
Cuándo
Al hacer ciertas acciones, Al conectar o tras un mantenimiento
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Servidor: cambiar el protocolo para agrupar varios pasos en una sola solicitud y respuesta (p. ej., incluir el inventario actualizado en la respuesta de la compra). Cliente: descargar de antemano los datos necesarios, usar una interfaz que no espere el resultado.
Cifras de referencia
Tiempo total ≈ número de idas y vueltas × (ping + procesamiento del servidor + espera del tick). Con 5 idas y vueltas y 150 ms de ping, unos 0.85–1 s.
En el gráfico
Siempre alto · Tiempo de finalización por función, idas y vueltas por acción
Dónde mirar
En una captura de paquetes del lado del servidor (Wireshark), contar cuántas veces se alternan solicitudes y respuestas, y con qué intervalo, mientras una cuenta de prueba hace una sola acción, como una compra en la tienda o el inicio de sesión. Si hay logs de solicitudes del servidor, agruparlos por ID de sesión y ver el número de solicitudes y la hora de llegada y de respuesta de cada una
Se confirma si
Una sola acción provoca varias idas y vueltas sucesivas en las que cada solicitud espera la respuesta anterior, el tiempo de finalización es aproximadamente idas y vueltas × RTT, y la misma función va proporcionalmente más lenta para los jugadores de regiones con ping alto
Se descarta si
Si hay solo una o dos idas y vueltas pero una respuesta tarda mucho, la causa está en el procesamiento del servidor o en la BD. Si todos los jugadores van igual de lentos sin importar el ping, revisar la carga del servidor
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)

Fuentes

  1. Chatty I/O antipattern Microsoft Azure
    Muchas solicitudes de E/S pequeñas acumulan latencia y empeoran mucho la capacidad de respuesta. Se recomienda agruparlas en menos solicitudes y más grandes

Ver también

Misma capa: Diseño del netcode

Causas de otras capas con el mismo síntoma (Input lag)

Ver la ficha interactiva con gráficos y simulaciones