Quando o buffer de envio de um jogador com conexão lenta enche e o servidor envia no modo bloqueante (em que a chamada só retorna quando abre espaço no buffer), a thread do servidor fica esperando esse único jogador.
Por quê O buffer de envio de um cliente lento enche → Efeito Como o envio é bloqueante, a thread do servidor espera até abrir espaço no buffer → Na tela Travamento e câmera lenta para todos os jogadores daquela thread
Aleatoriamente, de vez em quando, Quando junta muita gente
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Usar envio não bloqueante, limitar a fila de envio por cliente, descartar atualizações velhas.
No gráfico
Picos aleatórios · Tempo de tick do servidor, Send-Q por conexão
Onde olhar
Procurar com ss -tn as conexões com Send-Q (bytes sem ACK ou ainda não enviados) cheio até o tamanho do buffer de envio, e ver no thread dump (pilhas) do servidor do jogo, no momento do pico de tick, se há threads paradas numa chamada send
Confirma se
Quando há uma conexão lenta com Send-Q cheio, a thread responsável por ela está parada no send, e só os jogadores dessa mesma thread travam juntos
Descarta se
Thread parada esperando fora do send (lock, chamada ao BD): “Contenção de lock”, “Chamadas síncronas na thread do jogo”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes
send(2) — Linux manual pageLinux man-pages Sem espaço no buffer de envio, send() bloqueia; no modo não bloqueante, retorna na hora com EAGAIN
send function (winsock2.h)Microsoft No Winsock, send também bloqueia quando falta espaço no buffer, a menos que o socket esteja em modo não bloqueante
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Valores Recv-Q e Send-Q do ss: no socket em escuta, as conexões esperando o accept e o limite do backlog; no socket conectado, os bytes que o app ainda não leu e os bytes enviados ainda sem ACK