Socket.io: desconexão inexplicável 'fim de transporte' após a atualização

0.9.1 poderia ter introduzido um bug com batimentos cardíacos desencadeando desconexões prematuras.
Estou investigando isso e posso ter um 0.9.2 amanhã

Idem. Vendo desconexões / reconexões repetidas no Chrome e FF no Mac, cliente e servidor na mesma máquina.
Facilmente visto a partir de exemplos de socket.io no readme, configurações padrão intactas.

Tendo o mesmo problema ... Também notei que imediatamente após o soquete ser desconectado um novo soquete foi instanciado.

A solução alternativa para mim foi definir manualmente o tempo limite de fechamento:

io.configure( function() {
    io.set('close timeout', 60*60*24); // 24h time out
});

Eu também estava tendo esse problema. Obrigado steffenwt pela solução alternativa.

Sim, eu também tenho esse erro. Comecei a aprender socket.io há alguns dias e pensei que estava fazendo algo errado.

O downgrade para 0.9.0 funciona.

Não tenho certeza se é relevante, mas o soquete fecha a cada dois batimentos cardíacos. Então é assim

heartbeat2 gets sent and recieved all fine
heartbeat3 gets sens but never gets recieved
disconnect

Faça login aqui:

   debug - emitting heartbeat for client 18615332192056708826
   debug - websocket writing 2::
   debug - set heartbeat timeout for client 18615332192056708826
   info  - transport end
   debug - set close timeout for client 18615332192056708826
   debug - cleared close timeout for client 18615332192056708826
   debug - cleared heartbeat timeout for client 18615332192056708826
   debug - discarding transport

Eu também tenho o problema.

Eu uso 0,91-1.

Eu tento, mas tem esse problema.

io.configure (function () {
io.set ('tempo limite de fechamento', 60_60_24); // tempo limite de 24h
});

mesmo problema aqui

Você fez downgrade para 0.9.0? Agora marquei como mais recente no NPM

mesmo problema aqui para 0.9.1-1, juste rebaixado para 0.9.0 e o problema desapareceu.

como solução alternativa, você pode enviar alguns keep-alive do cliente, por exemplo, 20 segundos e responder imediatamente aos do servidor:

cliente: setInterval (function () {socket.emit ("keep-alive", null)}, 20 * 1000);
servidor: socket.on ('keep-alive', função (dados) {socket.emit ('keep-alive', null);});

FWIW: Se você estiver atendendo ao cliente de um servidor diferente e seu código de cliente não for rebaixado para 0.9.0, você ainda verá o problema.

Fiz o downgrade de 'socket.io' para 0.9.0 e ainda vejo o problema. Então eu fiz downgrade de socket.io-client para 0.9.0 e não consigo a desconexão.

Além disso, os transportes que experimentei que falharam são sockets da web e xhr-polling.

Esse problema deve ser resolvido, certo?

Eu tenho o mesmo problema. Mas percebi que é porque tenho haproxy.

Meu problema está aqui:

frontend all 0.0.0.0:80
    default_backend www_backend
    acl is_websocket path_beg /socket.io
    acl is_websocket hdr(Upgrade) -i WebSocket
    acl is_websocket hdr_beg(Host) -i ws
    timeout client 1000

Bem na linha "timeout client 1000" (mudei para 1 segundo para ver se era o problema, e era ...).

Portanto, agora estou pesquisando se existe uma maneira de alterá-lo apenas para os back-ends de websocket.

Espero que isso ajude alguém: +1:

Para sua informação, ainda estou vendo esse problema também, com xhr-polling e 0.9.14. Há uma desconexão forçada a cada 25 segundos. O log é idêntico ao anterior.

Também posso verificar que isso está acontecendo com o servidor 0.9.14 e o cliente 0.9. Embora não desconecte a cada 25 segundos, ele desconecta intermitentemente. Eu rastreei a chamada stream.emit ('end'); em node.js '_stream_readable.js. Acho que é o resultado da leitura de EOF no buffer.

@citosid por que o tempo limite do cliente haproxy causaria isso?

Acontecendo com 0.9.16. Mesma coisa que para BoarK

O suporte socket.io está morto?

@joefaron Tem que haver apoio antes que ele morra. Portanto, não, o suporte Socket.IO não está morto, simplesmente nunca existiu.

O mesmo problema aqui com Socket.io 0.9.16 - Vendo conexões caindo a cada ~ 25 segundos e logs mostrando "descartando transporte" ao mesmo tempo.

O downgrade para 0.8.6 corrigiu basicamente tudo para mim .. e estou usando
jsonp-polling em vez de xhr-polling como backup para websocket .. parece longe
mais estável.

No domingo, 26 de janeiro de 2014 às 10h16, Aran Reeks [email protected] :

O mesmo problema aqui com Socket.io 0.9.16 - Vendo conexões caindo a cada ~ 25
segundos e logs mostrando "descartando transporte" ao mesmo tempo.

-
Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/LearnBoost/socket.io/issues/777#issuecomment -33325205
.

Olá @joefaron ,

Eu estive brincando um pouco com as diferentes opções de configuração esta noite e irei examiná-las amanhã, mas posso confirmar que o problema está falhando nas verificações de pulsação. Essas verificações existem para garantir que as conexões com um usuário ainda sejam necessárias e que eles não tenham saído sem enviar uma desconexão por qualquer motivo.

Consegui replicar esse bug no Firefox e na versão estável atual do Chrome (32.0.1700.76 m).

Inicialmente, tentei desabilitar completamente os batimentos cardíacos, pois para nosso aplicativo eles não seriam realmente necessários, isso pode ser feito da seguinte maneira (de acordo com os documentos atuais, embora quando tentei isso parecia remover todos os métodos de transporte e acabou constantemente travando e reiniciando).
io.set('heartbeats', false);

Como isso falhou, minha próxima tentativa foi aumentar o tempo limite entre as solicitações de pulsação, o que pode ser feito usando o seguinte em seu app.js:
io.set('heartbeat timeout', 99999); // 99999 being the time between requests in seconds - Default is 25, please choose your value as applicable for your applications

Isso funcionou muito bem para nosso aplicativo, já que não nos importamos com as desconexões do cliente, mas pode não ser uma opção viável em seu ambiente.

Para qualquer outra pessoa com esse problema, caso ajude, meu ambiente é o seguinte:
NodeJS: v0.10.24 Socket.io: v0.9.16 Centos 6.5

Acho que esse é um problema realmente urgente / crítico. Por que ainda não foi resolvido? Dois anos se passaram desde o início deste tópico de edição.

Também estou tendo este problema:

NodeJS: v0.10.24
Socket.io: v0.9.16

d-oliveros: Eu sugiro fortemente o rebaixamento para 0.8.6. Eu não tive isso
problema .. e eu não acho que a compilação mais recente será corrigida em um futuro próximo.

No sábado, 15 de fevereiro de 2014 às 20:55, d-oliveros [email protected] :

Acho que esse é um problema realmente urgente / crítico. Por que não foi
resolvido ainda? Dois anos se passaram desde o início deste tópico de edição.

Também estou tendo este problema:

NodeJS: v0.10.24
Socket.io: v0.9.16

Responda a este e-mail diretamente ou visualize-o em Gi tHubhttps: //github.com/LearnBoost/socket.io/issues/777#issuecomment -35177466
.

Tente o novo master , este problema foi resolvido.

Haverá uma versão 0.9.17 que inclua uma correção para esse problema?

@fgnass você pode reproduzi-lo com 1.0.0-pre ?

@guille parece estar bem até agora! Eu avisarei você se ocorrer novamente.

Olá @guille, há alguma maneira de essa correção ser introduzida na 0.9.16? Apenas que usamos node.js / socket.io em um ambiente de produção bem estabelecido e terei dificuldade em justificar o uso de versões de pré-lançamento de qualquer aspecto de nossa plataforma. Se um patch pudesse ser feito para 0.9.16 ou, se 1.0.0 estivesse para ser lançado em um futuro (muito) próximo, isso seria muito preferível.

+1 para @eggysplat

@ aran112000 obrigado pela heartbeat timeout solução alternativa. Funciona para mim na v0.9.16.

Na verdade eu encontrei o motivo pelo qual tive esse problema. Muito embaraçoso, pensei que estava usando a v0.9.16 quando na realidade estava usando a v0.9.0 que tinha aquele bug. Ele foi corrigido na v0.9.2 por https://github.com/LearnBoost/socket.io/commit/57a0b2406004e46ec34729392ee289191a4f78e7 e https://github.com/LearnBoost/socket.io/commit/df5f23d3091df3bbf296ae3ae9609df3bbf296ae3ae96091df3bbf296ae3ae95260

Certifique-se de não ter heartbeat interval maior que heartbeat timeout como era na v0.9.0.

editar a postagem para que outras pessoas fiquem cientes:

desperdicei algumas horas de rastreamento de bugs, até que decidi testar o problema com meu mac. parece que meu antivírus no windows 8 também estava bloqueando as conexões e fazendo com que coisas caíssem. depois de desinstalá-lo, tudo funciona bem.

post relevante está realmente aqui, mas muito difícil de encontrar.
https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software

Eu sou meio que iniciante no socket.io e isso me levou mais de dois dias. Depois de enviar / receber dados, o cliente se desconecta e se reconecta, então o valor de socket.id muda

socket.io:client client close with reason transport close +39s
socket.io:socket closing socket - reason transport close +44s
.
.
.
socket.io:namespace adding socket to nsp / +4.1m
socket.io:socket socket connected - writing packet +1s

Finalmente, descobri que há uma exceção dentro de um retorno de chamada, então socket.io se desconecta e reconecta silenciosamente do sistema.

socket.on('someEvent', function(){
    var a = null;
    a.b; //You won't be aware of this error, this error is suppressed and won't be shown on console. 
         //Moreover, it disconnects and reconnects
})

Veja também este comentário

Portanto, ele detecta o erro silenciosamente e não mostra nada no console. Por que ele suprime o erro e desconecta / reconecta sem nem mesmo me notificar?

1.3.5 erros ainda estão lá

É isso?

Sim, o problema ainda existe em 1.3.5 ...

Problema ainda existe

Sim, o problema ainda está ocorrendo no 1.3.5, corrija

Acho que este é um problema de tempo limite do cliente haproxy, como

Eu tenho o mesmo problema, mas não estou usando o haproxy. Alguém sabe a última versão em que isso funcionou?

Ok, também estou recebendo relatórios de que o problema não foi 100% corrigido em nosso sistema. O engraçado é que eu poderia reproduzir o problema de forma confiável definindo "timeout client 1" no haproxy para um segundo e detectar o bug em nosso front-end.

Solicitado por isso, aumentei o "tempo limite do cliente" para um número maior e pensei que o problema iria embora, já que o keepalive / heartbeat de socket.io teria tempo suficiente para atualizar a conexão. Essa suposição provavelmente está errada, e vou mantê-los informados se descobrir mais coisas.

Eu postei isso em uma postagem stackoverflow e para alguns de vocês isso pode resolvê-lo:
"Parece que HackTimer.js e ccapture.js substituem window.setTimeout por uma função personalizada. HackTimer.js parece funcionar bem se for executado antes de qualquer outro JavaScript. Para ccapture.js, você pode tentar ter certeza de que está executado como o primeiro script. Portanto, o SocketIO primeiro usa o setTimeout nativo do seu navegador que, em seguida, é surpreendido pelo setTimeout personalizado que interrompe qualquer um dos temporizadores em execução no momento. "

Pesquise seu código para ver se uma de suas bibliotecas o está substituindo:

ag 'window.setTimeout\s*='

Você também pode testar em seu console para ver se setTimeout foi modificado:

/native/.test(window.setTimeout) // returns true for the native function and false for a custom one

Este bug ainda existe? Eu atualizei para a versão master e qualquer dispositivo móvel se desconecta em cerca de 2 minutos com aviso próximo de Transporte.

Isso foi o que fez mexer longe do socket.io 1> e me manteve no socket.io 0.9.17. Mas agora estou tentando novamente, definir um pingue-pongue manualmente no servidor para mantê-lo ativo e agora desconecta após 19 minutos .. o intervalo é a cada 35 segundos ..

Se eu executar o socket.io 0.9.17, este problema não está presente ... mas eu não quero mais usá-lo, pois está sendo preterido. Qualquer ajuda, isso acontece no navegador em dispositivos móveis.

@utan quais são as etapas de reprodução?

Olá @rauchg ,

Obrigado pela sua resposta..

1) Instale socket.io 1.4.0
2) definir a configuração do nginx para proxy

                        proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $host;
                proxy_http_version 1.1;
                proxy_pass http://io_nodes;

3) Defina seu cliente usando socket.io 1.4.0 / 2015-11-28
4) Conecte-se em um dispositivo móvel.
5) Deixe o navegador móvel conectado ao seu aplicativo e, em seguida, deixe o telefone inativo.

então logs;

  engine:polling compressing +0ms
  engine:socket executing batch send callback +1ms
PuTTY  engine intercepting request for path "/socket.io/" +95ms
  engine handling "GET" http request "/socket.io/?EIO=3&transport=polling&t=L8YVUt6&sid=DJNvvkhmCQew_3vGAAAB" +0ms
  engine setting new request for existing client +0ms
  engine:polling setting request +0ms
  engine:socket transport error +6s
  engine:polling closing +2ms
  engine:polling transport writable - closing right away +0ms
  engine:polling writing "�1" +0ms
  socket.io:client client close with reason transport error +0ms
  socket.io:socket closing socket - reason transport error +0ms

Você é desconectado após 3 4 minutos ..

Se estiver usando polling, você obterá este log de erro;

 engine:socket executing batch send callback +1ms
PuTTY  engine intercepting request for path "/socket.io/" +106ms
  engine handling "GET" http request "/socket.io/?EIO=3&transport=polling&t=L8YXgi6&sid=skadf3It4qBRi0S0AAAC" +1ms
  engine setting new request for existing client +0ms
  engine:polling setting request +0ms
  engine:socket transport error +3s
  engine:polling closing +0ms
  engine:polling transport writable - closing right away +0ms
  engine:polling writing "�1" +0ms
  socket.io:client client close with reason transport error +1ms
  socket.io:socket closing socket - reason transport error +2ms
  engine intercepting request for path "/socket.io/" +373ms
  engine handling "POST" http request "/socket.io/?EIO=3&transport=polling&t=L8YXhdB&sid=skadf3It4qBRi0S0AAAC" +0ms

Então @rauchg fechou?

Realmente não acho que você deveria.

Eu não fiz.

@rauchg ,
Portanto, este é um comportamento normal para socket.io agora? algo mudou no protocolo WS que agora desconecta usuários em dispositivos móveis se eles não estiverem plugados e estiverem ociosos?

Estou batendo minha cabeça na parede com esse problema, ele não me deixa completar uma atualização .. e refatorar meu código com o novo socket.io ...
Meu servidor Ubuntu 10.10
Versão Nginx: Nginx / 1.8.0
Node v0.10.31 // se eu atualizar para 4.0 é a mesma coisa ..

usando https e Nginx proxy socket.io ..

Alguém mais está tendo os mesmos problemas ou sou apenas eu?

Acho que também posso ser .. muito difícil localizar meu caso. Estou usando sails.js com socket.io.

ubuntu 14.04
nó v5.3.0
npm v 3.3.12
velas. [email protected]
socket.io@~1.4.3

Meu cliente é uma mistura de socket.io-client e sails.io.js:

var socketIOClient = require('socket.io-client');
var sailsIOClient = require('sails.io.js');
var io = sailsIOClient(socketIOClient);
io.socket.on('connect', function(data){....})

Portanto, a conexão inicial dura para sempre ... mas depois de um .emit () ou .broadcast () para este cliente, o servidor despeja o cliente após ~ 25 segundos a 1min E ... o cliente não é notificado da desconexão . Ele acha que ainda está conectado.

Muito frustrante.

Estou tendo um problema semelhante, mas apenas se usar um soquete seguro (wss em vez de ws). Com o ws tudo funciona bem, mas com o wss a conexão é interrompida esporadicamente em momentos aleatórios (cerca de 15 minutos). Sem firewalls, sem proxies.

Obrigado @ andrin-n-dream, acho que o meu está relacionado ao SSL também. Eu tenho uma máquina windows como cliente e meu ubuntu vm (mesma máquina) como servidor. Adaptador de rede em ponte. Nunca tive problemas com a conexão de rede geral.

Acontece em SSL, independentemente de eu usar SSL nginx ou terminação SSL sails.js.

NAVER - http://www.naver.com/

Email enviado para

O destinatário bloqueou o recebimento do seu e-mail.

Eu depurei para sempre e não consegui encontrar outra solução para SSL a não ser reconectar manualmente. Seria ótimo se engine.io fizesse isso por mim e tentasse novamente quando o transporte fosse fechado.

existe uma solução para isso? estou tendo exatamente o mesmo problema. após alguns segundos, obtenho um tempo limite de pulsação no log de depuração do servidor, mas o cliente ainda pensa que está conectado.

Bem, devido a outros problemas urgentes, atualizei meu env e agora está em segundo plano. Seria bom ver se o nó 6.5.0 faz alguma diferença. Sails.js atualizou alguns pacotes e mudou o uso dessas funções de baixo nível ...

Eu simplesmente não tenho tempo para mergulhar nisso novamente agora, pois estou migrando uma grande quantidade de C ++ legado. Talvez ainda este ano ou janeiro.

isso ainda está acontecendo em 2.0.3 ...
https://github.com/socketio/socket.io/issues/3025

sem uma solução alternativa, o socket.io é basicamente inutilizável porque 25% dos seus clientes terão esse problema.

io.set ('tempo limite de pulsação', 99999);

@ Aaron1011 Isso significa código do lado do servidor ou do cliente? Se for do lado do servidor, algo precisa ser alterado no lado do cliente?

Testado:
io.set ('tempo limite de pulsação', 99999);
No lado do servidor e não corrigiu o problema usando socket.io v 2.0.3. Vou tentar fazer o downgrade para 0.8.6 a seguir.

Não foi possível fazer o downgrade para 0.8.6 porque, de fato, é uma enorme toca de coelho. Toda a sintaxe mudou e como não há documentação que possa encontrar no 0.8.6, é uma causa perdida. Eu realmente não estou com vontade de reescrever meu aplicativo para fazer o downgrade para uma versão antiga na esperança de que isso possa corrigir esse problema.

Alguém tem alguma ideia / correção para v2.03? Coisas que eu tentei:

• definir pingInterval para 9999999
• definir pingTimeout para 99999999
• enviar mensagens automaticamente como um keep-alive. Eu envio uma mensagem a cada 1 segundo, mas ainda recebo as desconexões aleatórias.
• Firewall desativado
• Tentativa de ativação / desativação da pesquisa de XHR
• Porta alterada de algo aleatório para 80

Tenho certeza de que não é um erro de codificação, mas é específico do PC, pois ocorre em alguns e não em outros. Pode ter algo a ver com a adaptação da rede.

@forgeableSun você deve escrever seu aplicativo baseado no Primus, eu refatorei meu aplicativo com o primus e atualmente estou usando socketJs com ele ..

Apoie algum outro projeto sem necessidade de alterar o código em outro para usar qualquer outro projeto em tempo real.

Cumprimentos.

@utan , adoraria experimentar. mas como exatamente faço para mudar de socket.io com uma linha de código? Não parece haver nenhum exemplo de troca de outras estruturas.

npm install browserchannel --save

var primus = novo Primus (servidor, {transformador: 'browserchannel'});

https://github.com/primus/primus/blob/master/README.md#supported -real-time-frameworks

A esperança ajuda.

o que o canal do navegador tem a ver com socket.io?

Este é apenas um exemplo de como mudar para uma estrutura diferente.

Como você pediu um exemplo ..

ok, mas socket.io nem mesmo está listado como um dos frameworks em tempo real com suporte. nunca é apenas uma linha de código para alternar APIs, não vejo como os documentos podem anunciar isso sem dar exemplos.

Ouça, socket.io está com bugs depois de> = 1 ele tem desconexões estranhas, eu sugerindo usar o primus para que você possa mudar para um framework diferente ..

É por isso que te dei um exemplo, é claro que você precisará refatorar o código para usar o primus, então depois de você estará livre para tentar diferentes frameworks para ver qual é o melhor para você ou se um quebrar, então você usa um diferente ..

Cumprimentos

@utan, estou a ver, estava a pensar que era um transformador para mudar de um framework para outro com todo o aplicativo escrito nesse framework (como um adaptador). Mas, na verdade, é um transformador para alternar perfeitamente para estruturas com o aplicativo inteiro escrito no primus.

Na verdade, você subiu minha cabeça .. eu não sou tão proficiente para saber a diferença, pensei que estávamos falando sobre a mesma coisa ..

Cumprimentos.

Meus logs de servidor:
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"
cliente desconectar. Motivo da desconexão: "transporte fechado"

Mudei para ws (https://github.com/websockets/ws), que envolveu reescritas massivas, mas agora eu uso o objeto de navegador websocket nativo no lado do cliente e tudo funciona perfeitamente. Eu não tenho mais o problema. Até so socket.io!

Eu estava recebendo desconexões aleatórias após 10 a 30 minutos. Lembrei-me de que meu serviço de hospedagem executa NodeJS com Passenger em um servidor Apache compartilhado. Eu realmente não entendo, mas basicamente deve haver problemas com websockets neste tipo de integração. Estou testando com a configuração transports: ['polling'] apenas, enquanto no localhost eu executo com transports: ['websockets', 'polling'] sem erros e falhas. Até agora tudo bem depois de 30min ...