Eu acho que a resposta é não.
O problema foi resolvido com a substituição do software em questão, mas as ideias ainda são bem-vindas.
Atualmente, estou lutando com algum tipo de software de servidor (personalizado) que não aceita suas conexões adequadamente (escrito em Java por um programador PHP que nunca tocou em soquetes e muito menos em threads). Meu palpite é que um thread está morrendo antes que o soquete seja aceito corretamente no thread do cliente. Eu não posso ter certeza e, na verdade, não importa muito, já que o software está atualmente reimplementado; a versão antiga tem que ser mantida em execução até que a nova versão fique on-line, o mais confiável possível, mas sem tempo e dinheiro gastos na depuração da antiga base de código.
O bug se manifesta na seguinte saída netstat; algumas conexões nunca são transferidas do kernel para usar o espaço (é assim que eu interpreto isso, melhores interpretações são bem-vindas):
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
Quando isso acontece e os clientes se reconectam, eles tendem a funcionar. Mas eles não vão se reconectar por si só até que eles tenham um tempo bastante longo. Como o protocolo full-duplex personalizado em sua atual encarnação não reconhece nenhum dado enviado pelo cliente e este último não espera nenhuma solicitação recebida regularmente do servidor, isso pode levar dias, já que o cliente envia seus dados alegremente até que o kernel Receber fila executa cheio. No lado do servidor (kernel), deve ser possível detectar soquetes obsoletos, já que os clientes enviam dados regularmente.
Portanto, supondo que minha interpretação deste problema esteja correta, o que eu me perguntei é se existe um parâmetro do kernel que eu possa ajustar o que faz o kernel soltar / fechar conexões TCP com um RST se não forem lidos pelo espaço do usuário em tempo hábil.Melhores explicações sobre o que acontece aqui também são bem-vindas.
Você pode tentar ajustar TCP keepalive para valores muito mais curtos. Por padrão, uma conexão pode ficar ociosa por duas horas antes que o keepalive seja acionado.
Exatamente os valores que você deve usar depende, de fato, do que o seu aplicativo faz e do que os usuários esperam ou como eles interagem com ele.