Socket.io: “Fechamento de transporte” contínuo no cliente

Qualquer novidade sobre este problema, porque eu tenho exatamente o mesmo problema!

Eu também tenho o mesmo problema quando implanto no k8ns, mas quando executo localmente, ele funciona bem.

Eu também estou sofrendo com isso ...

@ talas9 @muhammadnasr @htamop as perguntas comuns para poder depurar / reproduzir o problema:

• qual versão do cliente / servidor você está usando?
• qual navegador?
• é reproduzível com o violino ?

Obrigado!

Eu tentei com cliente e servidor 2.1.0 e 2.0.4. No Chrome e Safari (mais recente).
Quando executo localmente, ele funciona bem (pode ser conectado por mais de uma hora sem desconectar), mas quando implanto no K8ns atrás do balanceador de carga de ingresso, esse problema acontece ...

A conexão para conhecimento é fechada exatamente após 25 segundos todas as vezes, veja a captura de tela

@ talas9 @htamop @ dnwldbs84 você está usando um balanceador de carga?

@darrachequesne Qual (is) balanceador (es) de carga você recomenda usar com socket.io?

@muhammadnasr @darrachequesne
Usei o servidor 2.1.0 e o cliente 1.0.0 (android)
Preciso manter a conexão estável por 8 a 9 horas, mas desconecta inesperadamente.
Mudei ambas as versões para 1.7.4 e 0.8.3? de acordo com outro posto de solução. Vou tentar testar se funciona bem amanhã

Eu não tinha usado um balanceador de carga. Tanto o cliente quanto o servidor usavam a versão 2.0.3 do Socket.io (não me lembro de todas as versões que usei). Não sei qual navegador está causando o problema No entanto, a maioria dos usuários já usou o Chrome. No meu caso, a desconexão foi aleatória, por isso não pode ser reproduzida.
E eu mudei para ws. Não tenho certeza se o problema foi resolvido.

@muhammadnasr @darrachequesne @ dnwldbs84
Acho que está resolvido no meu caso.
Eu uso o 0.8.3 socket.io-client no serviço android foreground (api 26) e a versão 1.3.5 no servidor nodejs.
No entanto, o problema pode não ser a versão.
Alterei o pingInterval no servidor para 10ms e parece funcionar corretamente (o tempo limite do ping e o fechamento do transporte não ocorreram)
var io = require ('socket.io') (http, {pingInterval: 10, pingTimeout: 4000});

10 milissegundos é muito estreito, dessa forma a rede ficará sobrecarregada.

10 milésimos de segundo é estreito, dessa forma a rede ficará sobrecarregada.

Correto!

@muhammadnasr qualquer balanceador de carga deve funcionar. Por favor, veja os seguintes exemplos:

• https://github.com/socketio/socket.io/tree/master/examples/cluster-haproxy
• https://github.com/socketio/socket.io/tree/master/examples/cluster-nginx
• https://github.com/socketio/socket.io/tree/master/examples/cluster-httpd

No entanto, a sessão fixa é necessária se você habilitar a votação (que é o padrão).

@darrachequesne Eu tenho o mesmo problema, depois de 8 ~ 9 horas o soquete desconecta com o motivo do "transporte fechado"

Estou a usar:

Chrome: 61.0.3163.100
Electron: 2.0.2
Socket.io: 2.1.1

Tive o mesmo problema, foi capaz de corrigi-lo usando o CDN a partir deste comentário https://github.com/socketio/socket.io/issues/3025#issuecomment -329024833 e definindo o tempo limite e o intervalo como abaixo:

io.set('heartbeat timeout', 60000);
io.set('heartbeat interval', 25000);

Ei,
Temos o mesmo problema com o socket.io quando ele é executado no Kubernetes e no controlador de entrada NGINX.
Quando a configuração do nginx é recarregada, ele recria o processo e todas as comunicações existentes são descartadas, o que causou o transport close , qualquer outra implantação que usa o controlador de ingresso pode causar o recarregamento da configuração

Em primeiro lugar, muito obrigado por este projeto incrível.

Mesmo problema aqui, talvez eu traga algo novo para você.

Eu tenho um servidor ws e um cliente ws no nó js.
Este cliente ws é usado a partir de um aplicativo node js onde é um serviço (micro serviço).

Outros clientes ws de navegadores da web (de aplicativos clientes) estão se comunicando por meio do servidor ws com este serviço node js.

Tudo está funcionando conforme o esperado.

Nos testes de estresse agora (10 clientes estão solicitando dados intensamente), no final dos testes, quando todos os jobs e transações tiverem sido finalizados, a conexão do serviço é fechada com o erro "transporte fechar". Isso nem sempre está acontecendo.

Esta é a configuração do servidor:
pingTimeout: 15000,
pingInterval: 20000,
Parece que durante a carga pesada alguns ping (s) foram perdidos ...? ou não sei.
Isso é algo que eu deveria esperar?

Além disso, com a configuração padrão pingTimeout: 2000, recebia este erro no meio do teste de estresse. Isso também foi completamente inesperado, mas digamos que o servidor estivesse sobrecarregado e não pudesse responder em 2 segundos (!) E poderíamos obter esse erro. Mas agora com pingTimeout: 15000 acontece quase 50% e somente após o término dos testes.

Hmho, acredito que os microsserviços deveriam esperar esse tipo de erro, mesmo que estejam rodando na mesma lan, mas a questão é por que isso está acontecendo?

Tentei criar uma pequena configuração para reproduzir este problema, mas não consegui.

Como ativar os logs? o DEBUG = socket.io * não está funcionando. Embora a variável esteja definida, não obtenho nenhuma saída.

Eu acredito fortemente que isso está relacionado ao # 2924.
As reconexões em um cliente são causadas por alguns navegadores (safari e cromo) que limitam os temporizadores para guias inativas para economizar bateria.
Isso resulta em mensagens de pulsação atrasadas do cliente e do servidor fechando a conexão devido ao pingTimeout.
Aumentar o pingTimeout funciona até certo ponto, mas ainda consigo reconectar em um ambiente de produção.

Eu também tenho o mesmo problema quando implanto no k8ns, mas quando executo localmente, ele funciona bem.

@muhammadnasr onde você conseguiu superar o problema de implantação no K8s? Estou tendo problemas semelhantes.

@ bheema01 apenas certifique-se de ter ativado a stickysession em seu proxy / balanceador de carga e deve funcionar

Recebi o mesmo erro

Mesmo problema ... os clientes se conectam e se desconectam repetidamente quando o endpoint do soquete do lado do servidor está atrás de um balanceador de carga. Mesmo depois de configurar sessões fixas, o problema ainda existe. @muhammadnasr foi capaz de resolver o problema.

Eu vi esse erro, quando o thread foi bloqueado com frequência por mais de 200ms.
Se isso acontecer com frequência, isso é ruim para o socket.io _e para seu aplicativo também_.
O socket.io tem um tempo limite para verificar a pulsação da conexão.
Se esse tempo limite for excedido, ele desligará a conexão e obteremos este erro.

@varunSabnis depois de consertar a sessão pegajosa, tudo funcionou perfeitamente.

@dennisat Tentei verificar quanto tempo levou para meu cliente receber um pacote de pong. Toda vez que passava de 200ms, o que foi testado tanto com servidor de soquete na nuvem quanto com servidor de soquete no meu host local. A configuração local não desconecta o soquete (tudo funciona bem), enquanto na configuração da nuvem o soquete conecta e desconecta continuamente. Portanto, não acho que seja esse o problema.
@muhammadnasr ok, isso é ótimo. Já o habilitei, mas ainda tenho alguns problemas.

@muhammadnasr @darrachequesne @ dnwldbs84
Acho que está resolvido no meu caso.
Eu uso o 0.8.3 socket.io-client no serviço android foreground (api 26) e a versão 1.3.5 no servidor nodejs.
No entanto, o problema pode não ser a versão.
Alterei o pingInterval no servidor para 10ms e parece funcionar corretamente (o tempo limite do ping e o fechamento do transporte não ocorreram)
var io = require ('socket.io') (http, {pingInterval: 10, pingTimeout: 4000});

Funciona magicamente, obrigado !!!!!!!

Acho que tenho 'transporte fechado' a cada intervalo de ping.

Eu estava realmente cansado desse problema.
Acho que vocês deveriam verificar a versão de "socket.io" com "socket.io-client".
se a versão do servidor / cliente for incompatível, a conexão estava muito instável.

Eu recomendo simplesmente usar o CDN como abaixo para o cliente.