Actualmente estoy luchando con un software de servidor (personalizado) de mala calidad que no acepta sus conexiones correctamente (escrito en Java por un programador de PHP que nunca antes había tocado sockets y mucho menos subprocesos). Supongo que un hilo muere antes de que el socket sea aceptado correctamente en el hilo del cliente. No puedo estar seguro y en realidad no importa mucho ya que el software está actualmente reimplementado; la versión anterior debe seguir ejecutándose hasta que la nueva versión esté en línea, lo más confiable posible pero sin gastar tiempo ni dinero en depurar el código base anterior.
El error se manifiesta en el siguiente resultado de netstat; algunas conexiones nunca se transfieren desde el kernel para usar espacio (así es como interpreto esto, se aceptan mejores interpretaciones):
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp6 228 0 192.0.2.105:1988 46.23.248.10:7925 ESTABLISHED -
tcp6 0 0 192.0.2.105:1988 221.130.33.37:9826 ESTABLISHED 14741/java
tcp6 0 0 192.0.2.105:1988 46.23.248.2:5867 ESTABLISHED 14741/java
tcp6 2677 0 192.0.2.105:1988 221.130.33.37:15688 ESTABLISHED -
tcp6 3375 0 192.0.2.105:1988 221.130.33.36:3045 ESTABLISHED -
tcp6 14742 0 192.0.2.105:1988 46.23.248.17:4679 ESTABLISHED -
tcp6 774 0 192.0.2.105:1988 212.9.19.73:36064 ESTABLISHED -
tcp6 92 0 192.0.2.105:1988 46.23.248.19:7164 ESTABLISHED -
tcp6 0 0 192.0.2.105:1988 46.23.248.21:6322 ESTABLISHED 14741/java
tcp6 0 0 192.0.2.105:1988 221.130.39.216:13937 ESTABLISHED 14741/java
tcp6 3051 0 192.0.2.105:1988 211.139.145.104:31239 ESTABLISHED -
tcp6 246 0 192.0.2.105:1988 46.23.248.10:5458 ESTABLISHED -
tcp6 618 0 192.0.2.105:1988 212.9.19.73:20209 ESTABLISHED -
tcp6 1041 0 192.0.2.105:1988 46.23.248.18:7424 ESTABLISHED -
tcp6 0 0 192.0.2.105:1988 46.23.248.10:5065 ESTABLISHED 14741/java
Cuando esto sucede y los clientes se vuelven a conectar, tienden a trabajar. Pero no se volverán a conectar por sí solos hasta que pase un tiempo de espera bastante largo. Dado que el protocolo full-duplex personalizado en su encarnación actual no reconoce ningún dato enviado por el cliente y este último no espera ninguna solicitud entrante regular del servidor, pueden pasar días desde que el cliente envía sus datos felizmente hasta que el kernel la cola de recepción está llena. En el lado del servidor (kernel) debería ser posible detectar sockets obsoletos ya que los clientes envían datos con regularidad.
Entonces, asumiendo que mi interpretación de este problema es correcta, lo que me preguntaba era si hay un parámetro del kernel que pueda ajustar y que haga que el kernel cierre/desconecte las conexiones TCP con un RST si el espacio del usuario no las lee en el momento oportuno. manera.
También son bienvenidas mejores explicaciones de lo que sucede aquí.
Respuesta1
Puedes intentar sintonizarTCP mantener activoa valores mucho más cortos. De forma predeterminada, una conexión puede estar inactiva durante dos horas antes de que se active keepalive.
Los valores exactos que debe utilizar dependen realmente de lo que hace su aplicación y de lo que esperan sus usuarios o de cómo interactúan con ella.
Respuesta2
Supongo que la respuesta es no.
El problema se resolvió reemplazando el software en cuestión, pero aún así se agradecen ideas.