Socket.io: por que socket.io usa conexão de websocket e xhr polling paralelamente?

• "XHR polling" não é uma conexão, pode usar mais de uma conexão.
• O websocket e os transportes de polling ainda não foram inicializados simultaneamente. Na verdade, é isso que engine.io faz e o que socket.io fará em breve, uma vez que o implementar. Leia mais aqui e você pode reconsiderar o rótulo de "estúpido", talvez.

Se você estiver se deparando com uma situação em que o socket.io 0.9 tem dois transportes abertos simultaneamente, isso seria um bug, e mais informações sobre como reproduzi-lo seriam apreciadas.

"XHR polling" não é uma conexão, pode usar mais de uma conexão.

Sim, mas porque a votação funciona no mesmo url de todos os pedidos. Suponho que deveria emular um.

Se você estiver se deparando com uma situação em que o socket.io 0.9 tem dois transportes abertos simultaneamente, isso seria um bug, e mais informações sobre como reproduzi-lo seriam apreciadas.

Não tenho certeza se queremos dizer o mesmo, mas: O Chromium me mostra uma conexão de websocket aberta e, além disso, está enviando solicitações de votação para socket.io.
O "estúpido" agora significa que não posso seguir o benefício de uma conexão e votação de websocket utilizável.
A conexão do websocket não deveria ser suficiente e o xhr polling apenas ser usado como fallback?

Corrija-me se eu perdi algo

@bodokaiser a conexão do websocket realmente funcionou ou está retornando ao polling?

Lembre-se de que o handshake é HTTP normal

Chrome me mostra que a conexão do websocket está pendente. Não há nenhuma mensagem de erro. Presumo que o ws funcione. No entanto, como posso verificar se socket.io está caindo?

Sim, definitivamente não é o aperto de mão. Vejo no cromo e no console do nó como as solicitações get são repetidas a cada 2.000 ms.

O registro node.js ajudaria você?

Cumprimentos

Inspecione os frames que foram trocados na conexão ws (acho que só o Chrome tem isso). Se você não vir nenhum dado, isso não funcionou.

Sim, parece estar recuando:

  debug - client authorized
   info  - handshake authorized yUEmr7drZfmWzWHdEZcp
GET /socket.io/1/?t=1344799805756 200 3ms
   debug - setting request GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815866
   debug - setting poll timeout
   debug - client authorized for 
   debug - clearing poll timeout
   debug - xhr-polling writing 1::
   debug - set close timeout for client yUEmr7drZfmWzWHdEZcp
GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815866 200 1ms
   debug - xhr-polling received data packet 5:::{"name":"hello","args":["world"]}
POST /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815871 200 1ms
   debug - setting request GET /socket.io/1/xhr-polling/yUEmr7drZfmWzWHdEZcp?t=1344799815872
   debug - setting poll timeout
   debug - discarding transport
   debug - cleared close timeout for client yUEmr7drZfmWzWHdEZcp
   debug - clearing poll timeout
   debug - xhr-polling writing 8::
   debug - set close timeout for client T9eCOR7gCe3pLNtiEZco
   debug - xhr-polling closed due to exceeded duration
GET /socket.io/1/xhr-polling/T9eCOR7gCe3pLNtiEZco?t=1344799800945 200 20002ms
   debug - clearing poll timeout
   debug - xhr-polling writing 8::
   debug - set close timeout for client yUEmr7drZfmWzWHdEZcp
   debug - xhr-polling closed due to exceeded duration

@guille, você poderia me dizer por que é um fallback?

Qual navegador você está usando?

Chroms 21 para Mac OSX

Também estou vendo o mesmo problema no Chrome 21 / Windows 21.0.1180.79 m - há uma conexão de pesquisa JSONP (que parece bem-sucedida) com uma conexão WebSocket simultânea que nunca se conecta - está sempre no estado "Pendente". A mesma versão do Chrome no Mac parece adequada.

Isso não parece relacionado a firewall ou antivírus, todos os testes passam em websocketstest.org e websocket.org/echo.html.

Estou usando o socket.io 0.9, mas também parece estar presente na versão mais recente.

@guille Este problema também parece muito fácil de reproduzir. Acabei de visitar um site que usa o transporte WebSocket de socket.io:

http://beta.blaggart.com

Observe que, pelo menos no Chrome 21 no Windows, o status da conexão WS é sempre "Pendente".

Tentar com o master socket.io?

Acabei de tentar mestre e tenho o mesmo problema. Acho que este problema também pode ser um truque de # 998.

Além disso, pelo que vale a pena, a solução alternativa descrita em # 998 funcionou para mim em conseguir uma conexão para estabelecer - desabilitando websockets e usando apenas xhr e jsonp polling.

isso é realmente um bug do Chrome?

ao fazer um teste em www.websocket.org/echo.html

O engraçado é que quando eu uso "Secure WebSocket (TLS)" no mesmo site, o websocket funciona.

exatamente o mesmo comportamento para Chrome e Firefox .. muito estranho ..

Servidor:

socket.on('loginout',function(){
    socket.emit('loginout',{uname:socket.name});
});

socket.on ('login', função (dados) {
socket.emit ('l_msg', {uname: data.uname, score: data.score, type: true});
});

Imprimir:
informações: handshake autorizado 11012331592122282453
depurar: configuração de solicitação GET /socket.io/1/xhr-polling/11012331592122282453?t=1353485202761
depurar: definir o tempo limite da sondagem
debug: cliente autorizado para
depurar: limpar o tempo limite da sondagem
debug: xhr-polling writing 1 ::
depurar: definir o tempo limite de fechamento para o cliente 11012331592122282453
debug: xhr-polling recebeu pacote de dados 20 5 ::: {"name": "count"} 22 5 ::: {"name": "history"} 23 5 ::: {"name ":"Lista de usuários"}
depurar: configuração de solicitação GET /socket.io/1/xhr-polling/11012331592122282453?t=1353485202792
depurar: definir o tempo limite da sondagem
depurar: descartando transporte
depurar: tempo limite de fechamento apagado para cliente 11012331592122282453
depurar: limpar o tempo limite da sondagem
debug: xhr-polling writing 8 ::
depurar: definir o tempo limite de fechamento para o cliente 1896586469607627233
debug: xhr-polling fechado devido à duração excedida
debug: xhr-polling recebeu pacote de dados 5 ::: {"name": "login", "args": [{"uname": "gjjn", "pwd": "3f01728152a0225ff9806c401ffdbe77"}]}
depurar: limpar o tempo limite da sondagem
debug: xhr-polling writing 5 ::: {"name": "l_msg", "args": [{"uname": "gjjn", "type": true, "head": " http: //42.121. 14,234 / indefinido "}]}
depurar: definir o tempo limite de fechamento para o cliente 11012331592122282453
debug: xhr-polling recebeu pacote de dados 5 ::: {"name": "loginout"}
debug: websocket writing 5 ::: {"name": "l_msg", "args": [{"uname": "gregergre", "type": true, "head": " http://42.121.14.234/ undefined "}]}
depurar: emitindo pulsação para o cliente 5207531891749391108
debug: websocket writing 2 ::
depurar: definir o tempo limite de pulsação para o cliente 5207531891749391108
depurar: pacote de pulsação obtido
depurar: tempo limite de pulsação apagado para o cliente 5207531891749391108
depurar: definir intervalo de pulsação para cliente 5207531891749391108
debug: websocket writing 5 ::: {"name": "loginout", "args": [{}]}

O xhr-polling recebeu o pacote de dados 5 ::: {"name": "loginout"}.
Mas não resultado.

O mesmo aqui. Usei o mesmo código, mas funciona no Chrome MacOS, mas não no Chrome Windows

como reproduzir - https://gist.github.com/jonnsl/5021596

+1, corrija este problema .. @LearnBoost

Mesmo eu vendo isso, do meu lado vejo uma conexão Websocket e uma solicitação XHR repetida enviada ao servidor SOCKET.io

Parece que uma conexão de websocket resultou em sucesso, mas vejo uma solicitação XHR

Request URL:ws://localhost:5000/socket.io/?EIO=2&transport=websocket&sid=XcMblHoZ0x97QRn_AAAE
Request Method:GET
Status Code:101 Switching Protocols
Request Headers CAUTION: Provisional headers are shown.
Cache-Control:no-cache
Connection:Upgrade
Cookie:io=XcMblHoZ0x97QRn_AAAE
Host:localhost:5000
Origin:http://localhost:3000
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits, x-webkit-deflate-frame
Sec-WebSocket-Key:EZixwYoUHpFFpgrEOqiS+w==
Sec-WebSocket-Version:13
Upgrade:websocket
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
Query String Parametersview sourceview URL encoded
EIO:2
transport:websocket
sid:XcMblHoZ0x97QRn_AAAE
Response Headers
Connection:Upgrade
Sec-WebSocket-Accept:WHsiBZoW9stmULt+YX8wmNK1wx8=
Upgrade:websocket

Aqui, como os frames do websocket se parecem
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

E o Long Polling Request

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot%202014-07-09%2011.15.47.png

Estou executando no Google Chrome 35.0.1916.153

e a versão do problema de soquete é [email protected]

Eu tenho o mesmo problema. Alguma atualização? Usando SocketIO 1.0.6

A primeira solicitação é sempre XHR, então nós _atualizamos_ para WebSocket (se possível). A sondagem subsequente é abortada (pode haver um ciclo de sondagem extra em alguns casos, mas nunca mais do que 1)

@guille quanto ao que verifiquei, vejo uma repetição da sondagem XHR, mesmo que a ligação ao Websocket tenha sido estabelecida com sucesso

Oi,

Qual é a solução para resolver esse problema?

@rohittailor : Estou testando isso no cliente:

    <script src="/socket.io/socket.io.js"></script>
    <script>
        var socket = io.connect({transports: ['websocket']});
    </script>

E, até o momento, tudo bem. Está evitando completamente a conexão XHR.

Isso resolveu meu problema também, o websocket estava funcionando bem, mas também havia uma pesquisa de XHR suja. Obrigado @gonzalodiaz

Eu realmente gostaria de ver um cenário em que a atualização para WS com êxito, mas os ciclos de pesquisa XHR continuem indefinidamente no Web Inspector!

(uma demonstração, vídeo, GIF animado, qualquer coisa funciona)

Posso fornecer uma demonstração de acesso ao meu site, hospedado na nuvem do MS Azure amanhã. Você pode nos fornecer seu URL de teste e mais detalhes sobre como o socket.io está hospedado?

@guille Que tal isso?

Aqui, como os frames do websocket se parecem
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

E o Long Polling Request

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot%202014-07-09%2011.15.47.png

Isso continua indefinidamente? Existem frames duplicados no
respostas? Você poderia postar o log do servidor correspondente com DEBUG = * e o
log do navegador com localStorage.debug='*' quando esta situação acontecer?

-
Guillermo Rauch - @rauchg https://twitter.com/rauchg

Na terça-feira, 14 de outubro de 2014 às 22h59, Viren Negi [email protected]
escreveu:

@guille https://github.com/guille Que tal isso

Aqui, como os frames do websocket se parecem

https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

E o Long Polling Request

https://www.dropbox.com/s/pf7d56tp85864bg/Screenshot%202014-07-09%2011.15.47.png

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Automattic/socket.io/issues/991#issuecomment -59161273
.

@guille Eu vejo a resposta xhr repetir indefinidamente não tenho certeza sobre o quadro duplicado deixe-me ver se eu posso fornecer tudo o que você precisa

Não tenho certeza de como posso ser útil, mas estou percebendo que só posso me conectar a uma tomada da web se ela for segura. Houve algumas mudanças de segurança recentes que exigem um cabeçalho (como o CORS) para permitir conexões WebSocket não seguras?

WebSockets funcionou um mês atrás para mim, agora ele só funciona para conexões wss: //.
Chrome 38.0.2125.104 - Windows 8.1.1

Editar: na verdade, esses resultados podem ser um problema com http://www.websocket.org/echo.html
Não consegui testar em outro lugar

O sucesso da conexão WS depende realmente das capacidades da rede / servidor. O SSL garante que nada pode quebrá-lo antes que os dados sejam descriptografados (proxies / balanceadores de carga subsequentes ainda podem quebrá-lo).

Percebi que na verdade era um bug no código, ele nem mesmo pesquisou a conexão do WS, fiz uma alteração e funcionou. Se bem me lembro, vou olhar para a fonte modificada esta noite.

Mas se estiver funcionando para todos os outros, pode ser outra coisa que está errada com a minha configuração, mas não estava tentando conectar porque pensava que o WS não estava disponível sem tentar, alterando um && para um || consertou.

Eu gostaria de ouvir mais!

Ainda um (pequeno) problema, o cliente sempre faz solicitações de pesquisa em vez de tentar outro transporte. Eu tenho que especificar

{transports: ['websocket']}

Para fazer funcionar, mas o cliente deve tentar todos os transportes para encontrar o que está bom, certo?

Esse problema foi o motivo pelo qual comecei em 2012/13 a trabalhar em um pacote de soquete web "puro" próprio.

Este problema foi resolvido? Estou vendo algo semelhante, mas antes de começar a cavar fundo, queria fazer uma pesquisa rápida ... comentários?

O código mudou um pouco desde a última vez que comentei sobre esse problema. É improvável que seja o mesmo bug. Não consigo encontrar a linha que suspeitei estar causando o problema da última vez. Isso não quer dizer que seja consertado.

Meu código socket.io está atualmente bloqueado por um bug engine.io-client, então não uso o s.io há alguns meses, então não posso dizer com certeza se isso ainda é um problema.

@nevercast seu comentário sobre o wss funcionar, mas não estava totalmente certo no meu caso. Obrigado por apontar isso. Estou pesquisando esse problema há mais de uma semana. Descobri que, de alguma forma, qualquer conexão ws na minha rede estava sendo bloqueada, mas o wss funcionou bem.

Este site é ótimo: http://websocketstest.com/ ele informa quais portas são capazes de executar websockets em qualquer rede. Recomende verificar isso antes de se envolver muito na depuração do websocket.

Tenho um problema com o socket io, mas não sei onde estou errado.

a imagem acima mostra que funciona bem no local, mas a imagem abaixo foi capturada ao tentar no ambiente AWS.

Tenho um problema com o socket io, mas não sei onde estou errado.

a imagem acima mostra que funciona bem no local, mas a imagem abaixo foi capturada ao tentar no ambiente AWS.

enfrentando o mesmo problema