Socket.io: Continuo "cierre de transporte" en el cliente

Cualquier noticia sobre este problema, ¡porque tengo exactamente el mismo problema!

También tengo el mismo problema cuando implemento en k8ns pero cuando ejecuto localmente funciona bien.

Yo también estoy sufriendo por esto ...

@ talas9 @muhammadnasr @htamop las preguntas comunes para poder depurar / reproducir el problema:

• ¿Qué versión del cliente / servidor estás usando?
• que navegador
• ¿Es reproducible con el violín ?

¡Gracias!

Lo he probado con cliente y servidor 2.1.0 y 2.0.4. En Chrome y Safari (más reciente).
Cuando ejecuto localmente, funciona bien (se puede conectar durante más de una hora sin desconectarlo), pero cuando implemento en K8ns detrás del balanceador de carga de entrada, ocurre este problema ...

Para su información, la conexión se cierra exactamente después de 25 segundos cada vez, vea la captura de pantalla

@ talas9 @htamop @ dnwldbs84 ¿está utilizando un equilibrador de carga?

@darrachequesne ¿Qué balanceador (es) de carga recomienda usar con socket.io?

@muhammadnasr @darrachequesne
Usé el servidor 2.1.0 y el cliente 1.0.0 (Android)
Necesito mantener la conexión estable durante 8 ~ 9 horas, pero se desconecta inesperadamente.
¿Cambié ambas versiones a 1.7.4 y 0.8.3? según otro puesto de solución. Intentaré probar si funciona bien mañana

No había usado un equilibrador de carga. Tanto el cliente como el servidor usaron la versión 2.0.3 de Socket.io (no recuerdo todas las versiones que usé). No sé qué navegador está causando el problema. Sin embargo, la mayoría de los usuarios han utilizado Chrome. En mi caso, la desconexión fue aleatoria, por lo que no se puede reproducir.
Y cambié a ws. No estoy seguro de que el problema esté resuelto.

@muhammadnasr @darrachequesne @ dnwldbs84
Creo que está resuelto en mi caso.
Utilizo 0.8.3 socket.io-client en el servicio de primer plano de Android (api 26) y la versión 1.3.5 en el servidor nodejs.
Sin embargo, es posible que el problema no sea la versión.
Cambié pingInterval en el servidor a 10ms y parece funcionar correctamente (el tiempo de espera del ping y el cierre del transporte no se produjeron)
var io = require ('socket.io') (http, {pingInterval: 10, pingTimeout: 4000});

10 milisegundos es demasiado estrecho, de esta manera la red se verá desbordada.

10 milisegundos es estrechar, de esta manera la red se verá desbordada.

¡Correcto!

@muhammadnasr, cualquier equilibrador de carga debería funcionar. Consulte los siguientes ejemplos:

• 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

Sin embargo, se requiere una sesión fija si habilita el sondeo (que es el predeterminado).

@darrachequesne tengo el mismo problema, después de 8 ~ 9 horas, el enchufe se desconecta con el motivo de "transporte cerrado"

Estoy usando:

Chrome: 61.0.3163.100
Electron: 2.0.2
Socket.io: 2.1.1

Tuve el mismo problema, pude solucionarlo usando CDN de este comentario https://github.com/socketio/socket.io/issues/3025#issuecomment -329024833 y estableciendo el tiempo de espera y el intervalo como se muestra a continuación:

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

Oye,
Tenemos el mismo problema con socket.io cuando se ejecuta en Kubernetes y NGINX Ingress Controller.
Cuando se recarga la configuración de nginx, se recrea el proceso y se descartan todas las comunicaciones existentes, lo que provocó que transport close , cualquier otra implementación que use el controlador de entrada podría provocar la recarga de la configuración

En primer lugar, muchas gracias por este increíble proyecto.

El mismo problema aquí, tal vez le traiga algo nuevo.

Tengo un servidor ws y un cliente ws en el nodo js.
Este cliente ws se usa desde una aplicación de node js donde hay un servicio (microservicio).

Otros clientes ws de navegadores web (de aplicaciones cliente) se comunican a través del servidor ws con este servicio de nodo js.

Todo está funcionando como se esperaba.

En las pruebas de estrés ahora (10 clientes están solicitando datos intensamente), al final de las pruebas, cuando todos los trabajos y transacciones han finalizado, la conexión del servicio se cierra con el error "transporte cerrado". Esto no sucede siempre.

Esta es la configuración del servidor:
pingTimeout: 15000,
pingInterval: 20000,
Parece que durante la carga pesada se pierden algunos ping ...? o no lo se.
¿Es esto algo que debería esperar?

Además, con la configuración predeterminada pingTimeout: 2000, recibí este error en medio de la prueba de esfuerzo. Esto también fue completamente inesperado, pero digamos que el servidor estaba sobrecargado y no pudo responder en 2 segundos (!) Y podríamos obtener este error. Pero ahora con pingTimeout: 15000 pasa casi el 50% y solo después del final de las pruebas.

Hmho, creo que los microservicios deberían esperar este tipo de errores, incluso si se ejecutan en la misma LAN, pero la pregunta es ¿por qué está sucediendo esto?

Intenté crear una pequeña configuración para reproducir este problema pero no pude hacerlo.

¿Cómo activar los registros? el DEBUG = socket.io * no funciona. Aunque la variable está configurada, no obtengo ningún resultado.

Creo firmemente que esto está relacionado con # 2924.
Las reconexiones en un cliente son causadas por algunos navegadores (safari y chrome) que aceleran los temporizadores de las pestañas inactivas para ahorrar batería.
Esto da como resultado mensajes de latido retrasados ​​del cliente y el servidor que cierra la conexión debido a pingTimeout.
El aumento de pingTimeout funciona hasta cierto punto, pero aún obtengo reconexiones en un entorno de producción.

También tengo el mismo problema cuando implemento en k8ns pero cuando ejecuto localmente funciona bien.

@muhammadnasr, ¿ dónde pudo superar el problema de implementación en K8? Estoy experimentando problemas similares.

@ bheema01 solo asegúrese de tener stickysession habilitado en su proxy / loadbalancer y debería funcionar

Tengo el mismo error

El mismo problema ... los clientes se conectan y desconectan repetidamente cuando el extremo del socket del lado del servidor está detrás de un equilibrador de carga. Incluso después de configurar sesiones pegajosas, el problema persiste. @muhammadnasr pudieron resolver el problema.

He visto este error cuando el hilo se bloqueaba con frecuencia durante más de 200 ms.
Si esto sucede con frecuencia, es malo para socket.io _y también para su aplicación_.
El socket.io tiene un tiempo de espera para verificar el latido de la conexión.
Si se excede este tiempo de espera, se apaga la conexión y obtenemos este error.

@varunSabnis después de arreglar la sesión pegajosa, todo funcionó sin problemas.

@dennisat Intenté comprobar cuánto tiempo tardó mi cliente en recibir un paquete de pong. Cada vez fue más allá de 200ms, que se probó tanto con el servidor de socket en la nube como con el servidor de socket en mi localhost. La configuración local no desconecta el socket (todo funciona bien), mientras que en la configuración de la nube, el socket se conecta y desconecta continuamente. Entonces, no creo que ese sea el problema.
@muhammadnasr está bien, eso es genial. De hecho, lo he habilitado pero todavía tengo algunos problemas.

@muhammadnasr @darrachequesne @ dnwldbs84
Creo que está resuelto en mi caso.
Utilizo 0.8.3 socket.io-client en el servicio de primer plano de Android (api 26) y la versión 1.3.5 en el servidor nodejs.
Sin embargo, es posible que el problema no sea la versión.
Cambié pingInterval en el servidor a 10ms y parece funcionar correctamente (el tiempo de espera del ping y el cierre del transporte no se produjeron)
var io = require ('socket.io') (http, {pingInterval: 10, pingTimeout: 4000});

Funciona mágicamente, gracias !!!!!!!

Encuentro que tengo 'transporte cerca' cada intervalo de ping.

Estaba realmente cansado de este problema.
Creo que deberían comprobar la versión de "socket.io" con "socket.io-client".
si la versión del servidor / cliente no coincide, la conexión era muy inestable.

Recomiendo simplemente usar CDN como se muestra a continuación para el cliente.