Pérdida de la ráfaga de mensajes de aparición al entrar Initial spawn burst lost (unreliable channel, receive buffer, fragmentation)
ID de la causa pt-spawn-burst · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
En cuanto el personaje entra en una zona, el servidor envía de golpe los datos de aparición de decenas o cientos de entidades cercanas. Si se envían por un canal no confiable (unreliable), o si el búfer de recepción se desborda mientras el cliente no lee el socket porque está cargando, una parte se pierde y no vuelve a llegar.
Por qué Justo después de entrar, los datos de aparición llegan todos en un instante → Efecto El cliente que está cargando lee el socket tarde y se desborda el búfer de recepción del SO, o un paquete UDP grande se fragmenta y basta perder un fragmento para perderlo entero. En un canal no confiable, tampoco se reenvía → En pantalla Solo en el cliente que carga más lento faltan algunos NPC. Al salir del rango de visión y volver, aparecen
Al conectar o tras un mantenimiento, Al moverse o cambiar de zona
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Desarrollo de cliente (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Servidor: enviar los mensajes de aparición y desaparición siempre por un canal confiable con reenvío garantizado, y repartir en partes la información inicial. Cliente: recibir en un hilo separado de la carga, aumentar el tamaño del búfer de recepción.
Cifras de referencia
El tamaño predeterminado del búfer de recepción UDP en el cliente varía según el SO, pero suele ser de decenas a cientos de KB. Si los datos de entrada de una ciudad llena de gente superan ese tamaño, basta con que la carga impida leer el socket un momento para que se desborde.
En el gráfico
Avalancha tras la apertura · Volumen recibido justo después de entrar, mensajes de aparición perdidos
Dónde mirar
Comparar el número de mensajes de aparición que envió el servidor justo después de la entrada con los que recibió el cliente, y ver por qué canal (confiable o no confiable) se enviaron. En una captura de paquetes del lado del servidor, ver el volumen enviado a ese jugador justo después de entrar y los paquetes fragmentados (filtro de Wireshark ip.flags.mf == 1 || ip.frag_offset > 0)
Se confirma si
Se recibieron menos de los que se enviaron, los que faltan se agrupan en la ráfaga justo después de entrar, y se enviaron por un canal no confiable o los paquetes grandes estaban fragmentados. Ocurre más en el cliente que carga más lento
Se descarta si
Si se enviaron y se recibieron los mismos y aun así no se ve, se descartaron después de recibirlos (“Mensajes de aparición descartados durante la carga”) o es un problema del cálculo de visibilidad. Si faltan en cualquier momento, sin relación con la entrada, apunta a pérdida en la conexión
Se verifica con
Requiere logs y métricas del servidor o el cliente del juego