Socket.io: « Clôture de transport » continue sur le client

Des nouvelles sur ce problème, car j'ai exactement le même problème!

J'ai également le même problème lorsque je déploie sur k8ns, mais lorsque je l'exécute localement, cela fonctionne bien.

J'en souffre aussi...

@talas9 @muhammadnasr @htamop les questions courantes pour pouvoir déboguer / reproduire le problème :

• quelle version du client/serveur utilisez-vous ?
• quel navigateur ?
• est-ce reproductible au violon ?

Merci!

Je l'ai essayé avec le client et le serveur 2.1.0 et 2.0.4. Sur chrome et safari (dernier).
Lorsque j'exécute localement, cela fonctionne bien (peut être connecté pendant plus d'une heure sans déconnexion), mais lorsque je déploie sur K8ns derrière l'équilibreur de charge d'entrée, ce problème se produit ...

Pour info, la connexion est fermée exactement après 25 secondes à chaque fois, voir capture d'écran

@talas9 @htamop @dnwldbs84 utilisez-vous un équilibreur de charge ?

@darrachequesne Quel(s) équilibreur(s) de charge recommandez-vous d'utiliser avec socket.io ?

@muhammadnasr @darrachequesne
J'ai utilisé le serveur 2.1.0 et le client 1.0.0 (android)
Je dois maintenir la connexion stable pendant 8 à 9 heures, mais elle se déconnecte de manière inattendue.
J'ai changé les deux versions en 1.7.4 et 0.8.3 ? selon un autre poste de solution. je vais essayer de tester si ça marche bien demain

Je n'avais pas utilisé d'équilibreur de charge. Le client et le serveur ont tous deux utilisé la version 2.0.3 de Socket.io (je ne me souviens pas de toutes les versions que j'ai utilisées). Je ne sais pas quel navigateur est à l'origine du problème. Cependant, la plupart des utilisateurs ont utilisé Chrome. Dans mon cas, la déconnexion était aléatoire, donc elle ne peut pas se reproduire.
Et j'ai changé pour ws. Je ne sais pas si le problème est résolu.

@muhammadnasr @darrachequesne @dnwldbs84
Je pense que c'est résolu dans mon cas.
J'utilise 0.8.3 socket.io-client dans le service de premier plan Android (api 26) et la version 1.3.5 dans le serveur nodejs.
Cependant, le problème n'est peut-être pas la version.
J'ai changé pingInterval dans le serveur à 10 ms et il semble fonctionner correctement (le délai d'expiration du ping et la fermeture du transport ne se sont pas produits)
var io = require('socket.io')(http, {pingInterval: 10, pingTimeout: 4000 });

10 millisecondes est trop étroit, de cette façon le réseau sera submergé.

10 millisecondes, c'est trop étroit, de cette façon le réseau sera submergé.

Correct!

@muhammadnasr tout équilibreur de charge devrait fonctionner. Veuillez consulter les exemples suivants :

• 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

Sticky-session est cependant requis, si vous activez l'interrogation (qui est la valeur par défaut).

@darrachequesne J'ai le même problème, après environ 8 à 9 heures, la prise se déconnecte avec la raison de "fermeture du transport"

J'utilise:

Chrome: 61.0.3163.100
Electron: 2.0.2
Socket.io: 2.1.1

J'ai eu le même problème, j'ai pu le résoudre en utilisant CDN à partir de ce commentaire https://github.com/socketio/socket.io/issues/3025#issuecomment -329024833 et en définissant le délai d'attente et l'intervalle comme ci-dessous :

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

Hey,
Nous avons le même problème avec socket.io lorsqu'il s'exécute sous Kubernetes et NGINX Ingress Controller.
Lorsque la configuration de nginx est rechargée, elle recrée le processus et toutes les communications existantes sont supprimées, ce qui a causé le transport close , tout autre déploiement qui utilise le contrôleur d'entrée peut provoquer le rechargement de la configuration

Tout d'abord merci pour ce super projet.

Même problème ici, peut-être que je t'apporterai quelque chose de nouveau.

J'ai un serveur ws et un client ws sur le nœud js.
Ce client ws est utilisé à partir d'une application node js où se trouve un service (micro service).

D'autres clients ws des navigateurs Web (des applications clientes) communiquent via le serveur ws avec ce service node js.

Tout fonctionne comme prévu.

Sur les stress tests maintenant (10 clients demandent intensivement des données), à la fin des tests, lorsque tous les jobs et transactions ont été terminés, la connexion du service est fermée avec l'erreur "transport close". Cela ne se produit pas toujours.

Voici la config du serveur :
pingTimeout : 15000,
pingInterval: 20000,
Il semble que pendant la charge lourde, certains pings soient perdus... ? ou je ne sais pas.
Est-ce quelque chose à quoi je dois m'attendre ?

De plus, avec la configuration par défaut pingTimeout: 2000, j'obtenais cette erreur au milieu du test de résistance. C'était également complètement inattendu, mais disons que le serveur était surchargé et n'a pas pu répondre dans les 2 secondes (!) Et nous pourrions obtenir cette erreur. Mais maintenant avec pingTimeout : 15000 ça arrive à presque 50% et seulement après la fin des tests.

Hmho, je pense que les micro-services devraient s'attendre à ce genre d'erreurs, même s'ils s'exécutent sur le même réseau local, mais la question est pourquoi cela se produit-il ?

J'ai essayé de créer une petite configuration pour reproduire ce problème mais je n'y suis pas parvenu.

Comment activer les logs ? le DEBUG=socket.io* ne fonctionne pas. Bien que la variable soit définie, je n'obtiens aucune sortie.

Je crois fermement que cela est lié à #2924.
Les reconnexions sur un client sont causées par certains navigateurs (safari et chrome) qui ralentissent les onglets inactifs pour économiser la batterie.
Cela entraîne des messages de pulsation retardés du client et du serveur fermant la connexion en raison de pingTimeout.
L'augmentation de pingTimeout fonctionne dans une certaine mesure, mais je reçois toujours des reconnexions dans un environnement de production.

J'ai également le même problème lorsque je déploie sur k8ns, mais lorsque je l'exécute localement, cela fonctionne bien.

@muhammadnasr où avez-vous pu surmonter le problème de déploiement sur K8 ? Je rencontre des problèmes similaires.

@ bheema01 assurez-vous simplement que stickysession est activé sur votre proxy/loadbalancer et cela devrait fonctionner

J'ai la même erreur

Même problème ..... les clients se connectent et se déconnectent à plusieurs reprises lorsque le point de terminaison de socket côté serveur se trouve derrière un équilibreur de charge. Même après avoir configuré les sessions persistantes, le problème persiste. @muhammadnasr avez -vous pu résoudre le problème.

J'ai vu cette erreur, lorsque le fil a été bloqué fréquemment pendant plus de 200 ms.
Si cela se produit fréquemment, cela est mauvais pour le socket.io _et pour votre application également_.
Le socket.io a un délai d'attente pour vérifier le rythme cardiaque de la connexion.
Si ce délai est dépassé, la connexion s'arrête et nous obtenons cette erreur.

@varunSabnis après avoir passé .

@dennisat J'ai essayé de vérifier combien de temps il a fallu à mon client pour recevoir un paquet de pong. À chaque fois, c'était au-delà de 200 ms, ce qui a été testé à la fois avec le serveur de socket dans le cloud et le serveur de socket sur mon hôte local. La configuration locale ne déconnecte pas le socket (tout fonctionne bien), alors que dans le cloud, le socket se connecte et se déconnecte continuellement. Donc, je ne pense pas que ce soit le problème.
@muhammadnasr d' accord, c'est super. Je l'ai activé, mais j'ai toujours des problèmes.

@muhammadnasr @darrachequesne @dnwldbs84
Je pense que c'est résolu dans mon cas.
J'utilise 0.8.3 socket.io-client dans le service de premier plan Android (api 26) et la version 1.3.5 dans le serveur nodejs.
Cependant, le problème n'est peut-être pas la version.
J'ai changé pingInterval dans le serveur à 10 ms et il semble fonctionner correctement (le délai d'expiration du ping et la fermeture du transport ne se sont pas produits)
var io = require('socket.io')(http, {pingInterval: 10, pingTimeout: 4000 });

Cela fonctionne comme par magie, merci !!!!!!!

Je trouve que j'ai un "transport proche" à chaque intervalle de ping.

J'étais vraiment fatigué de ce problème.
Je pense que vous devriez vérifier la version de "socket.io" avec "socket.io-client".
si la version serveur / client ne correspond pas, la connexion était très instable.

Je recommande simplement d'utiliser CDN comme ci-dessous pour le client.