Socket.io: Desconexión inexplicable 'final de transporte' después de la actualización

0.9.1 podría haber introducido un error con latidos que desencadenan desconexiones prematuras.
Lo estoy investigando y podría tener un 0.9.2 mañana

Ídem. Ver desconexiones / reconexiones repetidas en Chrome y FF en Mac, cliente y servidor en la misma máquina.
Se ve fácilmente en los ejemplos de socket.io en el archivo Léame, la configuración predeterminada está intacta.

Teniendo el mismo problema ... También noté que inmediatamente después de que el socket se desconectaba, se creaba una instancia de un nuevo socket.

La solución para mí fue configurar manualmente el tiempo de espera de cierre:

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

Yo también estaba teniendo este problema. Gracias steffenwt por la solución.

Sí, también tengo este error. Empecé a aprender socket.io hace unos días y primero pensé que estaba haciendo algo mal.

La degradación a 0.9.0 funciona.

No estoy seguro de si es relevante, pero el zócalo se cierra cada dos latidos. Entonces va así

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

Iniciar sesión aquí:

   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

Yo también tengo el problema.

Yo uso 0.91-1.

Lo intento, pero tiene este problema.

io.configure (function () {
io.set ('tiempo de espera de cierre', 60_60_24); // 24 horas de espera
});

el mismo problema aqui

¿Bajaste a 0.9.0? Ahora lo marqué como el último en NPM

El mismo problema aquí para 0.9.1-1, solo bajó a 0.9.0, y el problema desapareció.

como solución, puede enviar algunos mensajes de mantenimiento desde el cliente, por ejemplo, 20 segundos y responder inmediatamente a los del servidor:

cliente: setInterval (function () {socket.emit ("mantener vivo", nulo)}, 20 * 1000);
servidor: socket.on ('mantener vivo', función (datos) {socket.emit ('mantener vivo', nulo);});

FWIW: Si está sirviendo al cliente desde un servidor diferente, y su código de cliente no se ha degradado a 0.9.0, seguirá viendo el problema.

Bajé 'socket.io' a 0.9.0 y todavía veía el problema. Luego bajé socket.io-client a 0.9.0 y no obtengo la desconexión.

Además, los transportes que he probado y que fallan son los sockets web y xhr-polling.

Este problema debería cerrarse, ¿verdad?

Tengo el mismo problema. Pero noté que es porque tengo haproxy.

Mi problema esta 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

Justo en la línea "timeout client 1000" (lo cambié a 1 segundo para ver si era el problema, y ​​era ...).

Así que ahora estoy buscando si hay una manera de cambiarlo solo para los backends de websocket.

Espero que esto ayude a alguien: +1:

Para su información, también sigo viendo este problema con xhr-polling y 0.9.14. Hay una desconexión forzada cada 25 segundos. El registro es idéntico al anterior.

También puedo verificar que esto está sucediendo con el servidor 0.9.14 y el cliente 0.9. Aunque no se desconecta cada 25 segundos, se desconecta de forma intermitente. Lo rastreé hasta una llamada stream.emit ('end'); en node.js '_stream_readable.js. Creo que es el resultado de leer EOF en el búfer.

@citosid ¿

Pasando con 0.9.16. Lo mismo que para BoarK

¿Está muerto el soporte de socket.io?

@joefaron Tiene que haber apoyo antes de que muera. Entonces no, el soporte de Socket.IO no está muerto, simplemente nunca existió.

El mismo problema aquí con Socket.io 0.9.16 - Ver conexiones caer cada ~ 25 segundos y registros que muestran "descartando transporte" al mismo tiempo.

La degradación a 0.8.6 solucionó básicamente todo para mí ... y estoy usando
jsonp-polling en lugar de xhr-polling como copia de seguridad de websocket ... parece lejos
mas estable.

El domingo, 26 de enero de 2014 a las 10:16 a. M., Aran Reeks [email protected] escribió:

El mismo problema aquí con Socket.io 0.9.16 - Ver conexiones caer cada ~ 25
segundos y registros que muestran "descartando transporte" al mismo tiempo.

-
Responda a este correo electrónico directamente o véalo en Gi
.

Hola @joefaron , aplausos por tu ayuda.

He estado jugando un poco con las diferentes opciones de configuración esta noche y lo investigaré más a fondo mañana, pero puedo confirmar que el problema es que fallan las comprobaciones de latido. Estas verificaciones están implementadas para garantizar que las conexiones con un usuario aún sean necesarias y que no se hayan ido sin enviar una desconexión por ningún motivo.

Pude replicar este error tanto en Firefox como en la versión estable actual de Chrome (32.0.1700.76 m).

Inicialmente intenté deshabilitar completamente los latidos del corazón, ya que para nuestra aplicación no iban a ser realmente necesarios, esto se puede hacer de la siguiente manera (de acuerdo con los documentos actuales, aunque cuando probé esto, pareció eliminar todos los métodos de transporte y terminó constantemente chocar y reiniciar).
io.set('heartbeats', false);

Como esto falló, mi siguiente intento fue aumentar el tiempo de espera entre las solicitudes de latido, lo que se puede hacer usando lo siguiente dentro de su 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

Esto funcionó de maravilla para nuestra aplicación, ya que no nos importan las desconexiones de los clientes, aunque puede que esta no sea una opción viable en su entorno.

Para cualquier otra persona con este problema en caso de que ayude, mi entorno es el siguiente:
NodeJS: v0.10.24 Socket.io: v0.9.16 Centos 6.5

Creo que este es un tema realmente urgente / crítico. ¿Por qué no se ha resuelto todavía? Han pasado dos años desde el inicio de este hilo temático.

También estoy experimentando este problema:

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

d-oliveros: Sugiero encarecidamente bajar la calificación a 0.8.6. No he tenido esto
problema ... y no creo que la última versión se solucione en un futuro próximo.

El sábado 15 de febrero de 2014 a las 8:55 p.m., d-oliveros [email protected] escribió:

Creo que este es un tema realmente urgente / crítico. ¿Por qué no ha sido
resuelto todavía? Han pasado dos años desde el inicio de este hilo temático.

También estoy experimentando este problema:

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

Responda a este correo electrónico directamente o véalo en Gi
.

Pruebe el nuevo master , este problema ha desaparecido.

¿Habrá una versión 0.9.17 que incluya una solución para este problema?

@fgnass ¿puedes reproducirlo con 1.0.0-pre ?

¡@guille se ve bien hasta ahora! Te avisaré si vuelve a ocurrir.

Hola @guille, ¿hay alguna forma de que esta solución se pueda introducir en 0.9.16? Solo que usamos node.js / socket.io en un entorno de producción bien establecido y me resultará difícil justificar el uso de versiones preliminares de cualquier aspecto de nuestra plataforma. Si se pudiera hacer un parche para 0.9.16 o, si 1.0.0 se lanzará en un futuro (muy) cercano, esto sería preferible.

+1 para @eggysplat

@ aran112000 gracias por la solución heartbeat timeout . Funciona para mí en v0.9.16.

De hecho, encontré la razón por la que tuve este problema. Muy vergonzoso, pensé que estaba usando v0.9.16 cuando en realidad estaba usando v0.9.0 que tenía ese error. Fue solucionado en v0.9.2 por https://github.com/LearnBoost/socket.io/commit/57a0b2406004e46ec34729392ee289191a4f78e7 y https://github.com/LearnBoost/socket.io/commit/df5f23d3091df3bbf296ae95260928

Asegúrese de no tener heartbeat interval más grande que heartbeat timeout como estaba en v0.9.0.

editar la publicación para que otros sepan:

Perdí algunas horas de seguimiento de errores, hasta que decidí probar el problema con mi mac. Parece que mi antivirus en Windows 8 también estaba bloqueando las conexiones y provocando que las cosas se cayeran. después de desinstalarlo, todo funciona bien.

La publicación relevante está aquí, pero es bastante difícil de encontrar.
https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software

Soy una especie de iniciador de socket.io y eso me llevó más de dos días. Después de enviar / recibir datos, el cliente se desconecta y se vuelve a conectar, por lo que cambia el valor de socket.id

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, descubrí que hay una excepción dentro de una devolución de llamada, por lo que socket.io se desconecta y se vuelve a conectar silenciosamente del 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
})

Ver también este comentario

Entonces, detecta silenciosamente el error y no me muestra nada en la consola. ¿Por qué suprime el error y se desconecta / vuelve a conectar sin siquiera notificarme?

1.3.5 los errores siguen ahí

¿Lo es?

Sí, el problema todavía existe en 1.3.5 ...

El problema sigue existiendo

Sí, el problema sigue ocurriendo en 1.3.5, por favor corríjalo

Creo que este es un problema de tiempo de espera del cliente haproxy, como ha señalado @citosid . Aumente el tiempo de espera del cliente haproxy para el backend de websocket y este problema debería solucionarse.

Tengo el mismo problema, pero no estoy usando haproxy. ¿Alguien sabe la última versión en la que esto estaba funcionando?

De acuerdo, también recibo informes de que el problema no está solucionado al 100% en nuestro sistema. Lo curioso es que pude reproducir el problema de manera confiable configurando "timeout client 1" en haproxy en un segundo, y experimentar el error en nuestra interfaz.

Impulsado por esto, aumenté el "cliente de tiempo de espera" a un número mayor y pensé que el problema desaparecería, ya que socket.io keepalive / heartbeat tendría tiempo suficiente para actualizar la conexión. Esta suposición probablemente sea incorrecta, y los mantendré informados si descubro más cosas.

Publiqué esto en una publicación de stackoverflow y para algunos de ustedes esto puede resolverlo:
"Parece que HackTimer.js y ccapture.js reemplazan window.setTimeout con una función personalizada. HackTimer.js parece funcionar bien si se ejecuta antes que cualquier otro JavaScript. Para ccapture.js, es posible que desee intentar asegurarse de que sea se ejecuta como el primer script. Entonces, SocketIO primero usa el setTimeout nativo de su navegador que luego queda impresionado por el setTimeout personalizado que rompe cualquiera de los temporizadores que se están ejecutando actualmente ".

Busque su código para ver si una de sus bibliotecas lo está reemplazando:

ag 'window.setTimeout\s*='

También puede probar en su consola para ver si setTimeout se ha modificado en absoluto:

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

¿Sigue existiendo este error? Actualicé a la versión maestra y cualquier dispositivo móvil se desconecta en aproximadamente 2 minutos con un aviso de cierre de transporte.

Esto fue lo que hizo que se alejara de socket.io 1> y me mantuvo en socket.io 0.9.17. Pero ahora estoy intentando de nuevo, configuro un ping pong manualmente en el servidor para mantenerlo vivo y ahora se desconecta después de 19 minutos .. el intervalo es cada 35 segundos ..

Si ejecuto socket.io 0.9.17, este problema no está presente ... pero no quiero usarlo más ya que está obsoleto. Cualquier ayuda, esto sucede en el navegador de los dispositivos móviles.

@utan ¿cuáles son los pasos de reproducción?

Hola @rauchg ,

Gracias por su respuesta..

1) Instale socket.io 1.4.0
2) establezca la configuración de nginx en 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) Configure su cliente usando socket.io 1.4.0 / 2015-11-28
4) Conéctese en un dispositivo móvil.
5) Deje el navegador móvil conectado a su aplicación y luego deje su teléfono inactivo.

luego registra;

  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

Te desconectas después de 3 a 4 minutos ..

Si utiliza el sondeo, obtendrá este registro de errores;

 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

¿Entonces @rauchg lo cerró?

Realmente no creo que debas.

No lo hice.

@rauchg ,
Entonces, ¿es este un comportamiento normal para socket.io ahora? ¿Cambió algo en el protocolo WS que ahora desconecta a los usuarios en dispositivos móviles si no están conectados y están inactivos?

Me estoy golpeando la cabeza contra la pared con este problema, no me permitirá completar una actualización ... y refactorizar mi código con un nuevo socket.io ...
Mi servidor Ubuntu 10.10
Versión de Nginx: Nginx / 1.8.0
Nodo v0.10.31 // si actualizo a 4.0 es lo mismo ..

usando https y Nginx proxy socket.io ..

¿Alguien más tiene los mismos problemas o solo soy yo?

Creo que yo también podría ser ... muy difícil precisar mi caso. Estoy usando sails.js con socket.io.

ubuntu 14.04
nodo v5.3.0
npm v 3.3.12
paño. [email protected]
socket.io@~1.4.3

Mi cliente es una mezcla de socket.io-client y 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){....})

Entonces, la conexión inicial dura para siempre ... pero luego, después de un .emit () o .broadcast () a este cliente, el servidor descarga al cliente después de ~ 25 segundos a 1 minuto Y ... el cliente no recibe una notificación de la desconexión . Cree que todavía está conectado.

Muy frustrante.

Tengo un problema similar, pero solo si uso un socket seguro (wss en lugar de ws). Con ws todo funciona bien, pero con wss la conexión se cae esporádicamente en momentos aleatorios (~ 15 minutos). Sin firewalls, sin proxies.

Gracias @ andrin-n-dream. Creo que el mío también está relacionado con SSL. Tengo una máquina con Windows como cliente y mi ubuntu vm (la misma máquina) como servidor. Adaptador de red con puente. Nunca he tenido problemas con la conexión de red general.

Ocurre en SSL independientemente de si uso la terminación SSL nginx o sails.js.

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

Correo electrónico enviado a

El destinatario ha bloqueado la recepción de su correo electrónico.

Depuraba para siempre y no pude encontrar otra solución para SSL que volver a conectar manualmente. Sería genial si engine.io hiciera esto por mí y lo volviera a intentar cuando el transporte esté cerrado.

¿Existe alguna solucion para esto? Estoy teniendo exactamente el mismo problema. después de unos segundos, obtengo un tiempo de espera de latido en el registro de depuración del servidor, pero el cliente todavía cree que está conectado.

Bueno, debido a otros problemas urgentes, he actualizado mi env y esto ahora está en un segundo plano. Sería bueno ver si el nodo 6.5.0 hace alguna diferencia. Sails.js ha actualizado algunos paquetes y ha cambiado el uso de estas funciones de bajo nivel ...

Simplemente no tengo tiempo para sumergirme en esto nuevamente en este momento, ya que estoy migrando una gran cantidad de C ++ heredado. Quizás a finales de este año o en enero.

esto todavía está sucediendo en 2.0.3 ...
https://github.com/socketio/socket.io/issues/3025

sin una solución alternativa, socket.io es básicamente inutilizable porque el 25% de sus clientes van a tener este problema.

io.set ('tiempo de espera de latido', 99999);

@ Aaron1011 ¿Está destinado a ser un código de cliente o del lado del servidor? Si es del lado del servidor, ¿es necesario cambiar algo en el lado del cliente?

Intentado:
io.set ('tiempo de espera de latido', 99999);
En el lado del servidor y no solucionó el problema usando socket.io v 2.0.3. Intentaré rebajar la calificación a 0.8.6 a continuación.

No se pudo rebajar a 0.8.6 porque de hecho es una madriguera enorme. Toda la sintaxis ha cambiado y, dado que no hay documentación que pueda encontrar en 0.8.6, es una causa perdida. Realmente no tengo ganas de reescribir mi aplicación para degradarla a una versión antigua con la esperanza de que pueda solucionar este problema.

¿Alguien tiene alguna idea / solución para la v2.03? Cosas que he probado:

• establecer pingInterval en 9999999
• establecer pingTimeout en 99999999
• enviando mensajes automáticamente como un mantener vivo. Envío un mensaje cada 1 segundo, pero sigo recibiendo desconexiones aleatorias.
• Cortafuegos desactivado
• Intenté con el sondeo XHR activado / desactivado
• Puerto cambiado de algo aleatorio a 80

Estoy seguro de que no es un error de codificación, pero es específico de la PC, ya que ocurre en algunos y no en otros. Podría tener algo que ver con la adaptación de la red.

@forgeableSun deberías escribir tu aplicación basada en Primus, refactoricé mi aplicación con primus y actualmente estoy usando socketJs con ella.

Admite algún otro proyecto sin necesidad de cambiar el código en otro para usar cualquier otro proyecto en tiempo real.

Saludos.

@utan Me encantaría probarlo. pero, ¿cómo cambio exactamente de socket.io con una línea de código? No parece haber ningún ejemplo sobre el cambio de otros marcos.

npm install browserchannel --save

var primus = new Primus (servidor, {transformador: 'canal del navegador'});

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

La esperanza ayuda.

¿Qué tiene que ver el canal del navegador con socket.io?

Ese es solo un ejemplo de cómo cambiar a un marco diferente ...

Como pediste un ejemplo ...

bien, pero socket.io ni siquiera figura como uno de los marcos de trabajo en tiempo real admitidos. Nunca es solo 1 línea de código para cambiar de API, no veo cómo los documentos pueden anunciar eso sin dar ningún ejemplo.

Escuche, socket.io tiene errores después de> = 1 tiene desconexiones extrañas, sugiero que use primus para que pueda cambiar a un marco diferente ...

Es por eso que le di un ejemplo, por supuesto que necesitará refactorizar el código para usar primus, luego podrá probar diferentes marcos para ver cuál es el mejor para usted o si uno se rompe, entonces usará uno diferente ...

Saludos

@utan Ya veo, estaba pensando que era un transformador para cambiar de 1 marco a otro con toda la aplicación escrita en ese marco (como un adaptador). Pero en realidad, es un transformador para cambiar sin problemas a marcos con toda la aplicación escrita en primus.

De hecho, subiste a mi cabeza ... no soy tan competente para saber la diferencia, pensé que estábamos hablando de lo mismo ...

Saludos.

Mi servidor registra:
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"
desconexión del cliente. Motivo de la desconexión: "transporte cerrado"

Cambié a ws (https://github.com/websockets/ws) que implicó reescrituras masivas, pero ahora uso el objeto del navegador websocket nativo en el lado del cliente y todo funciona perfectamente. Ya no tengo el problema. ¡Hasta luego socket.io!

Recibía desconexiones aleatorias después de 10 a 30 minutos. Recordé que mi servicio de alojamiento ejecuta NodeJS con Passenger en un servidor compartido Apache. Realmente no lo entiendo, pero básicamente se supone que hay problemas con los websockets en este tipo de integración. Estoy probando con la configuración de transportes: ['polling'] solamente, mientras que en el localhost corro con transportes: ['websockets', 'polling'] sin errores ni abandonos. Hasta ahora todo bien después de 30min ...