Si el búfer de envío de un jugador con una conexión lenta está lleno y se le envía en modo bloqueante (un envío cuya llamada no vuelve hasta que hay espacio en el búfer), el hilo del servidor se queda esperando a ese único jugador.
Por qué El búfer de envío de un cliente lento está lleno → Efecto Como el envío es bloqueante, el hilo del servidor espera hasta que haya espacio en el búfer → En pantalla Congelamiento o cámara lenta para todos los jugadores que atiende ese hilo
De vez en cuando, al azar, Cuando se junta mucha gente
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo)
Tareas (Equipo de desarrollo)
Usar envío no bloqueante, poner un tope a la cola de envío de cada cliente, descartar las actualizaciones viejas.
En el gráfico
Picos aleatorios · Tiempo de tick del servidor, Send-Q por conexión
Dónde mirar
Conexiones cuyo Send-Q (bytes sin ACK o aún sin enviar) llena el búfer de envío, con ss -tn; en el momento del pico de tick, si el volcado de hilos (pilas) del servidor del juego muestra hilos detenidos en una llamada a send
Se confirma si
Cuando hay una conexión lenta con el Send-Q lleno, el hilo que la atiende está detenido en send y solo se detienen a la vez los jugadores que atiende ese mismo hilo
Se descarta si
Si el hilo detenido espera fuera de send (un lock, una llamada a la BD): “Contención de locks”, “Llamadas síncronas en el hilo del juego”
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Fuentes
send(2) — Linux manual pageLinux man-pages Si no hay espacio en el búfer de envío, send() se bloquea; en modo no bloqueante, vuelve enseguida con EAGAIN
send function (winsock2.h)Microsoft En Winsock, send también se bloquea si no hay espacio en el búfer, salvo en modo no bloqueante
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Valores Recv-Q y Send-Q de ss: en un socket de escucha, conexiones esperando accept y límite del backlog; en un socket conectado, bytes que la aplicación aún no ha leído y bytes enviados que no han recibido ACK