No Linux, existe um tempo limite de soquete configurável entre o kernel e o espaço do usuário?

2

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.

    
por mss 04.09.2013 / 15:02

2 respostas

0

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.

    
por 17.01.2014 / 15:05
0

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.

    
por 04.09.2013 / 18:27

Tags