Atualmente estou lutando com algum software de servidor (personalizado) de baixa qualidade que não aceita suas conexões corretamente (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. Não tenho certeza e na verdade não importa muito, já que o software está reimplementado atualmente; a versão antiga deve ser mantida em execução até que a nova versão fique online, o mais confiável possível, mas sem gastar tempo e dinheiro na depuração da base de código antiga.
O bug se manifesta na seguinte saída do netstat; algumas conexões nunca são transferidas do kernel para usar espaço (é assim que 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 se reconectarão sozinhos até atingirem um tempo limite bastante longo. Como o protocolo full-duplex personalizado em sua encarnação atual 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 desde que o cliente envia seus dados com satisfação até o kernel a fila de recebimento está cheia. No lado do servidor (kernel) deve ser possível detectar soquetes obsoletos, uma vez que os clientes enviam dados regularmente.
Então, assumindo que minha interpretação deste problema esteja correta, o que eu me perguntei foi se existe um parâmetro do kernel que eu possa ajustar, o que faz com que o kernel interrompa/feche conexões TCP com um RST se elas não forem lidas pelo espaço do usuário em tempo hábil. maneiras.
Melhores explicações sobre o que acontece aqui também são bem-vindas.
Responder1
Você pode tentar ajustarManutenção de atividade TCPpara valores muito mais curtos. Por padrão, uma conexão pode ficar inativa por duas horas antes que o keepalive seja ativado.
Exatamente quais valores você deve usar depende realmente do que seu aplicativo faz e do que seus usuários esperam ou de como eles interagem com ele.
Responder2
Acho que a resposta é não.
O problema foi resolvido com a substituição do software em questão, mas ideias ainda são bem-vindas.