Rendimiento y lag«An existing connection was forcibly closed by the remote host» suena a fallo de red, y normalmente no lo es: es el aspecto que tiene un hilo de red saturado visto desde fuera, una vez que la conexión que se suponía que estaba atendiendo ya se ha rendido de esperar.
Qué está haciendo Netty por debajo
La capa de red de Minecraft corre sobre Netty, un marco de E/S asíncrona que le entrega la lectura y escritura de paquetes a un grupo pequeño de hilos dedicados, separado del hilo principal de lógica del juego. Esa separación es a propósito: es lo que deja al servidor seguir hablando con doscientos clientes sin que el tick del mundo tenga que esperar por ninguna conexión lenta en concreto.
Ese grupo sigue siendo finito. Si algo genera paquetes más rápido de lo que los hilos de Netty pueden serializarlos y mandarlos —un marcador que se reescribe cada tick para cada jugador, un plugin de hologramas empujando actualizaciones de metadatos sin parar, una ráfaga de paquetes malformados de un cliente con trampas—, la cola de salida se acumula. Un cliente cuya conexión lleva demasiado tiempo en silencio asume que el servidor desapareció y cierra el socket por su lado, que el servidor luego reporta como que la conexión se cerró a la fuerza, porque desde su punto de vista eso es exactamente lo que pasó.
Disparadores habituales
| Disparador | Por qué satura el hilo de red |
|---|---|
| Actualizaciones de marcador o lista de jugadores cada tick | Reescribe y reenvía datos estructurados a cada cliente conectado, cada tick |
| Plugins de holograma o texto flotante con muchas instancias | Cada uno sigue a los jugadores cercanos y empuja paquetes de metadatos de entidad sin parar |
| Bucles de restauración de skin/capa | Vuelve a pedir y a difundir datos de perfil una y otra vez en vez de guardarlos en caché |
| Paquetes malformados o excesivos de un cliente con trampas | Fuerza validación y procesamiento extra por paquete al entrar |
Como el error nombra un fallo de red, es fácil suponer que el borde o el firewall tienen la culpa. Las capas de mitigación y enrutamiento están completamente por delante de esto: la saturación pasa dentro del propio proceso del juego, entre sus propios hilos de Netty y su propia cola de paquetes salientes, y por eso el arreglo siempre está en lo que el servidor está mandando, no en la configuración de red.
/spark profiler durante las desconexiones nombra la fuente directamenteLos plugins que gastan muchos paquetes se ven claros en un perfil como tiempo en código de red o de envío de paquetes. Es un camino más rápido hasta la causa que probar plugins de uno en uno desactivándolos.