Socket.io: ¿Por qué socket.io usa la conexión websocket y el sondeo xhr en paralelo?

• El "sondeo XHR" no es una conexión, podría utilizar más de una conexión.
• Los transportes websocket y polling aún no se inicializan al mismo tiempo. De hecho, eso es lo que hace engine.io y lo que pronto hará socket.io una vez que lo implemente. Lea más aquí y quizás reconsidere la etiqueta de "estúpido".

Si se encuentra en una situación en la que socket.io 0.9 tiene dos transportes abiertos al mismo tiempo, eso sería un error, y se agradecería más información sobre cómo reproducirlo.

El "sondeo XHR" no es una conexión, podría utilizar más de una conexión.

Sí, pero debido a que el sondeo funciona en la misma URL todas las solicitudes. Supongo que debería emular uno.

Si se encuentra en una situación en la que socket.io 0.9 tiene dos transportes abiertos al mismo tiempo, eso sería un error, y se agradecería más información sobre cómo reproducirlo.

No estoy seguro de si queremos decir lo mismo, pero: Chromium me muestra una conexión websocket abierta y, además, envía solicitudes de sondeo a socket.io.
Lo "estúpido" ahora significa que no puedo seguir los beneficios de una conexión y un sondeo utilizables de websocket.
¿No debería la conexión websocket ser autosuficiente y el sondeo xhr solo debería usarse como respaldo?

Corrígeme si me perdí algo

@bodokaiser, ¿

Tenga en cuenta que el protocolo de enlace es HTTP normal.

Chrome me muestra que la conexión websocket está pendiente. No hay ningún mensaje de error. Supongo que el ws funciona. Sin embargo, ¿cómo puedo comprobar si socket.io está retrocediendo?

Sí, definitivamente no es el apretón de manos. Veo en Chrome y en la consola del nodo cómo se repiten las solicitudes de obtención cada 2000 ms.

¿Le ayudaría el registro de node.js?

Saludos

Inspeccione los marcos que se intercambiaron en la conexión ws (creo que solo Chrome tiene esto). Si no ve ningún dato, entonces no funcionó.

Sí parece estar retrocediendo:

  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, ¿ podrías decirme por qué es un retroceso?

¿Qué navegador estás usando?

Chroms 21 para Mac OSX

También veo el mismo problema en Chrome 21 / Windows 21.0.1180.79 m: hay una conexión de sondeo JSONP (que parece exitosa) con una conexión WebSocket simultánea que nunca se conecta; siempre está en el estado "Pendiente". La misma versión de Chrome en Mac parece estar bien.

Esto no parece estar relacionado con el firewall o el antivirus, todas las pruebas pasan en websocketstest.org y websocket.org/echo.html.

Estoy usando socket.io 0.9, pero también parece estar presente en la última versión.

@guille Este problema también parece bastante fácil de reproducir. Acabo de visitar un sitio que usa el transporte WebSocket de socket.io:

http://beta.blaggart.com

Tenga en cuenta que, al menos en Chrome 21 en Windows, el estado de la conexión WS siempre es "Pendiente".

¿Probar con socket.io master?

Intenté master y tengo el mismo problema. Creo que este problema también podría ser una trampa del # 998.

Además, por lo que vale, la solución alternativa descrita en el n. ° 998 me funcionó para establecer una conexión: deshabilitar los websockets y solo usar el sondeo xhr y jsonp.

¿Es esto realmente un error de Chrome?

al hacer una prueba en www.websocket.org/echo.html

Lo curioso es que cuando uso "Secure WebSocket (TLS)" en ese mismo sitio web, websocket funciona.

exactamente el mismo comportamiento para Chrome y Firefox ... muy extraño ...

Servidor:

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

socket.on ('iniciar sesión', función (datos) {
socket.emit ('l_msg', {uname: data.uname, score: data.score, type: true});
});

Impresión:
información: apretón de manos autorizado 11012331592122282453
depuración: solicitud de configuración GET /socket.io/1/xhr-polling/11012331592122282453?t=1353485202761
depuración: configuración del tiempo de espera de la encuesta
debug: cliente autorizado para
depuración: borrar el tiempo de espera de la encuesta
depuración: escritura xhr-polling 1 ::
depuración: establezca el tiempo de espera de cierre para el cliente 11012331592122282453
debug: paquete de datos recibido xhr-polling 20 5 ::: {"name": "count"} 22 5 ::: {"name": "history"} 23 5 ::: {"name ":"Lista de usuarios"}
depuración: solicitud de configuración GET /socket.io/1/xhr-polling/11012331592122282453?t=1353485202792
depuración: configuración del tiempo de espera de la encuesta
debug: descartando el transporte
depuración: se borró el tiempo de espera de cierre para el cliente 11012331592122282453
depuración: borrar el tiempo de espera de la encuesta
depuración: escritura xhr-polling 8 ::
depuración: establezca el tiempo de espera de cierre para el cliente 1896586469607627233
debug: xhr-polling cerrado debido a una duración excedida
debug: xhr-polling recibió el paquete de datos 5 ::: {"name": "login", "args": [{"uname": "gjjn", "pwd": "3f01728152a0225ff9806c401ffdbe77"}]}
depuración: borrar el tiempo de espera de la encuesta
debug: xhr-polling writing 5 ::: {"name": "l_msg", "args": [{"uname": "gjjn", "type": true, "head": " http: //42.121. 14.234 / undefined "}]}
depuración: establezca el tiempo de espera de cierre para el cliente 11012331592122282453
debug: xhr-polling recibió el paquete de datos 5 ::: {"name": "loginout"}
debug: websocket escribiendo 5 ::: {"name": "l_msg", "args": [{"uname": "gregergre", "type": true, "head": " http://42.121.14.234/ indefinido "}]}
depuración: emisión de latidos para el cliente 5207531891749391108
depuración: escritura de websocket 2 ::
depuración: establece el tiempo de espera del latido para el cliente 5207531891749391108
depuración: tengo el paquete de latidos del corazón
depuración: se borró el tiempo de espera del latido para el cliente 5207531891749391108
depuración: establece el intervalo de latido para el cliente 5207531891749391108
debug: websocket escribiendo 5 ::: {"name": "loginout", "args": [{}]}

El xhr-polling recibió el paquete de datos 5 ::: {"nombre": "loginout"}.
Pero no Resultado.

Lo mismo aquí. Usé el mismo código pero funciona en Chrome MacOS pero no en Chrome Windows

cómo reproducir - https://gist.github.com/jonnsl/5021596

+1, solucione este problema .. @LearnBoost

Incluso estoy viendo esto, en mi extremo veo una conexión Websocket y una solicitud XHR repetida enviada al servidor SOCKET.io

Parece que una conexión websocket resultó exitosa, pero veo una solicitud 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

Aquí cómo se ven los marcos websocket
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

Y la solicitud de votación larga

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

Estoy ejecutando Google Chrome 35.0.1916.153

y la versión del problema del socket es [email protected]

Tengo el mismo problema. ¿Alguna actualización? Usando SocketIO 1.0.6

La primera solicitud es siempre XHR, luego _actualizamos_ a WebSocket (si podemos). Se cancela el sondeo posterior (puede haber un ciclo de sondeo adicional en algunos casos, pero nunca más de 1)

@guille en cuanto a lo que verifiqué, veo un sondeo XHR repetido incluso si la conexión Websocket se estableció correctamente

Hola,

¿Cuál es la solución para resolver este problema?

@rohittailor : estoy probando esto en el cliente:

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

y hasta ahora todo bien. Está evitando por completo la conexión XHR.

Esto también resuelve mi problema, websocket funcionaba bien, PERO también había un sondeo XHR sucio. Gracias @gonzalodiaz

Realmente me gustaría ver un escenario en el que se actualice a WS con éxito, ¡pero los ciclos de sondeo XHR continúan indefinidamente en Web Inspector!

(una demostración, video, gif animado, cualquier cosa funciona)

Puedo darle un acceso de demostración a mi sitio web, alojado en la nube de MS Azure mañana. ¿Puede darnos su URL de prueba y más detalles sobre cómo está alojado socket.io?

@guille ¿Qué tal esto?

Aquí cómo se ven los marcos websocket
https://www.dropbox.com/s/v6szg9hka53erbc/Screenshot%202014-07-09%2011.12.33.png

Y la solicitud de votación larga

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

¿Siguen funcionando indefinidamente? ¿Hay fotogramas duplicados en el
respuestas? ¿Podría publicar el registro del servidor correspondiente con DEBUG = * y el
registro del navegador con localStorage.debug='*' cuando ocurre esta situación?

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

El martes 14 de octubre de 2014 a las 10:59 p.m., Viren Negi [email protected]
escribió:

@guille https://github.com/guille ¿Qué tal esto?

Aquí cómo se ven los marcos websocket

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

Y la solicitud de votación larga

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

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/Automattic/socket.io/issues/991#issuecomment -59161273
.

@guille Veo que la respuesta xhr se repite indefinidamente, no estoy seguro sobre el fotograma duplicado, déjame ver si puedo proporcionarte todo lo que necesitas.

No estoy seguro de lo útil que puedo ser, pero me doy cuenta de que solo puedo conectarme a un enchufe web si es seguro. ¿Ha habido algunos cambios de seguridad recientes que requieren un encabezado (como CORS) para permitir conexiones WebSocket no seguras?

WebSockets funcionó hace un mes para mí, ahora solo funciona para conexiones wss: //.
Chrome 38.0.2125.104 - Windows 8.1.1

Editar: estos resultados podrían ser un problema con http://www.websocket.org/echo.html
No he podido probar en otro lugar

El éxito de la conexión WS realmente depende de las capacidades de la red / servidor. SSL garantiza que nada puede romperlo antes de que se descifren los datos (aunque los proxies / balanceadores de carga posteriores aún pueden romperlo).

Me di cuenta de que en realidad era un error en el código, ni siquiera sondeó la conexión WS, hice un cambio y luego funcionó. Si recuerdo, miraré la fuente modificada esta noche.

Pero si funciona para todos los demás, podría ser algo más que esté mal en mi configuración, pero no intentaba conectarse porque pensó que WS no estaba disponible sin intentarlo, cambiando un && a un || arreglado.

¡Me gustaría escuchar más!

Aún siendo un problema (pequeño), el cliente siempre realiza solicitudes de sondeo en lugar de intentar otros transportes. Tengo que especificar

{transports: ['websocket']}

Para que funcione, pero el cliente debe probar todos los transportes para encontrar el bueno, ¿verdad?

Este problema fue la razón por la que comencé en 2012/13 a trabajar en un paquete de sockets web "puro" propio.

¿Se ha resuelto este problema? Estoy viendo algo similar, pero antes de comenzar a profundizar, quería hacer una búsqueda rápida ... ¿comentarios?

El código ha cambiado bastante desde la última vez que comenté este problema. Es poco probable que sea el mismo error. Parece que no puedo encontrar la línea que sospeché que estaba causando el problema la última vez. Eso no quiere decir que esté arreglado.

Mi código socket.io está bloqueado actualmente por un error engine.io-client, por lo que no he usado s.io durante algunos meses, por lo que no puedo decir con certeza si esto sigue siendo un problema.

@nevercast tu comentario sobre el funcionamiento de wss pero no fue del todo correcto en mi caso. Gracias por señalarlo. He estado buscando este problema durante más de una semana. Descubrí que de alguna manera se estaba bloqueando cualquier conexión ws en mi red, pero wss funcionó bien.

Este sitio web es genial: http://websocketstest.com/ le indica qué puertos pueden ejecutar websockets en una red determinada. Recomiende comprobar esto antes de involucrarse demasiado en la depuración de websocket.

Tengo un problema con el socket io pero no estoy seguro de dónde me equivoco.

la imagen de arriba muestra que funciona bien en local, pero la imagen de abajo se captura mientras se intenta en el entorno de AWS.

Tengo un problema con el socket io pero no estoy seguro de dónde me equivoco.

la imagen de arriba muestra que funciona bien en local, pero la imagen de abajo se captura mientras se intenta en el entorno de AWS.

enfrentando el mismo problema