Socket.io: déconnexion inexpliquée 'fin de transport' après la mise à niveau

0.9.1 aurait pu introduire un bogue avec des battements de cœur déclenchant des déconnexions prématurées.
Je me penche dessus et j'aurai peut-être un 0.9.2 demain

Idem. Voir des déconnexions / reconnexions répétées dans Chrome et FF sur Mac, client et serveur sur la même machine.
Facilement visible à partir des exemples socket.io dans le fichier readme, paramètres par défaut inchangés.

Ayant le même problème... J'ai également remarqué qu'immédiatement après la déconnexion du socket, un nouveau socket était instancié.

La solution de contournement pour moi consistait à définir manuellement le délai de fermeture :

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

J'avais aussi ce problème. Merci steffenwt pour la solution de contournement.

Oui, j'ai aussi cette erreur. J'ai commencé à apprendre socket.io il y a quelques jours et j'ai d'abord pensé que je faisais quelque chose de mal.

La mise à niveau vers la 0.9.0 fonctionne.

Je ne sais pas si c'est pertinent, mais le socket se ferme à chaque autre battement de cœur. Alors ça se passe comme ça

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

Connectez-vous ici :

   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

J'ai le problème aussi.

J'utilise 0.91-1 .

J'essaie, mais j'ai ce problème.

io.configure( fonction() {
io.set('délai de fermeture', 60_60_24); // 24h d'attente
});

Même problème ici

Avez-vous rétrogradé à 0.9.0 ? Je l'ai maintenant marqué comme le plus récent sur NPM

même problème ici pour la 0.9.1-1, juste rétrogradé à 0.9.0, et le problème a disparu.

comme solution de contournement, vous pouvez envoyer des keep-alives du client, disons 20 secondes et répondre immédiatement à ceux du serveur :

client : setInterval(function() { socket.emit("keep-alive", null) },20*1000);
serveur : socket.on('keep-alive', function (data) { socket.emit('keep-alive', null); });

FWIW : si vous servez le client à partir d'un serveur différent et que votre code client n'est pas rétrogradé à 0.9.0, vous verrez toujours le problème.

J'ai rétrogradé 'socket.io' à 0.9.0 et j'ai toujours vu le problème. Ensuite, j'ai rétrogradé socket.io-client à 0.9.0 et je n'obtiens pas la déconnexion.

En outre, les transports que j'ai essayés qui échouent sont les sockets Web et l'interrogation xhr.

Ce problème devrait être clos, non ?

J'ai le même problème. Mais j'ai remarqué que c'est parce que j'ai haproxy.

Mon problème est ici :

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

Juste dans la ligne "timeout client 1000" (je l'ai changé en 1 seconde pour voir si c'était le problème, et c'était le cas...).

Alors maintenant, je cherche s'il existe un moyen de le changer uniquement pour les backends websocket.

J'espère que cela aidera quelqu'un :+1:

Pour info, je vois toujours ce problème aussi, avec l'interrogation xhr et la 0.9.14. Il y a une déconnexion forcée toutes les 25 secondes. Le journal est identique à ci-dessus.

Je peux également vérifier que cela se produit avec le serveur 0.9.14 et le client 0.9. Bien qu'il ne se déconnecte pas toutes les 25 secondes, il se déconnecte par intermittence. Je l'ai tracé jusqu'à un appel stream.emit('end'); dans le _stream_readable.js de node.js. Je pense que c'est le résultat de la lecture d'EOF dans le tampon.

@citosid pourquoi le délai d'attente du client haproxy causerait-il cela ?

Passant avec 0.9.16. Même chose que pour BoarK

Le support socket.io est-il mort ?

@joefaron Il doit y avoir du soutien avant qu'il ne puisse mourir. Donc non, le support Socket.IO n'est pas mort, il n'a tout simplement jamais existé.

Même problème ici avec Socket.io 0.9.16 - Voir les connexions chuter toutes les ~ 25 secondes et les journaux indiquant "supprimer le transport" en même temps.

La rétrogradation vers la 0.8.6 a pratiquement tout corrigé pour moi .. et j'utilise
jsonp-polling au lieu de xhr-polling comme sauvegarde vers websocket .. semble loin
plus stable.

Le dimanche 26 janvier 2014 à 10h16, Aran Reeks [email protected] a écrit :

Même problème ici avec Socket.io 0.9.16 - Voir les connexions tomber tous les ~ 25
secondes et les journaux indiquant « rejeter le transport » en même temps.

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/LearnBoost/socket.io/issues/777#issuecomment -33325205
.

Salut @joefaron ,

J'ai joué un peu avec les différentes options de configuration ce soir et j'y reviendrai demain, mais je peux confirmer que le problème vient de l'échec des vérifications de pulsation. Ces contrôles sont en place pour s'assurer que les connexions à un utilisateur sont toujours nécessaires et qu'ils ne sont pas partis sans envoyer une déconnexion pour quelque raison que ce soit.

J'ai pu reproduire ce bogue à la fois dans Firefox et dans la version stable actuelle de Chrome (32.0.1700.76 m).

Au départ, j'ai essayé de désactiver complètement les battements de cœur car pour notre application, ils n'allaient pas vraiment être nécessaires, cela peut être fait comme suit (selon la documentation actuelle, bien que lorsque j'ai essayé cela, il semblait supprimer toutes les méthodes de transport et s'est retrouvé constamment plantage et redémarrage).
io.set('heartbeats', false);

Comme cela a échoué, ma prochaine tentative était d'augmenter le délai d'attente entre les demandes de pulsation, ce qui peut être fait en utilisant ce qui suit dans votre 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

Cela a fonctionné un régal pour notre application car nous ne nous soucions pas des déconnexions des clients, cela peut cependant ne pas être une option viable dans votre environnement.

Pour toute autre personne ayant ce problème au cas où cela aiderait, mon environnement est le suivant :
NodeJS: v0.10.24 Socket.io: v0.9.16 Centos 6.5

Je pense que c'est une question vraiment urgente / critique. Pourquoi n'est-il pas encore résolu ? Deux ans se sont écoulés depuis le début de ce fil de discussion.

Je rencontre aussi ce problème :

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

d-oliveros : Je suggère fortement de passer à 0.8.6. je n'ai pas eu ça
problème .. et je ne pense pas que la dernière version sera corrigée dans un proche avenir.

Le samedi 15 février 2014 à 20h55, d-oliveros [email protected] a écrit :

Je pense que c'est une question vraiment urgente / critique. Pourquoi n'a-t-il pas été
encore résolu ? Deux ans se sont écoulés depuis le début de ce fil de discussion.

Je rencontre aussi ce problème :

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

Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/LearnBoost/socket.io/issues/777#issuecomment -35177466
.

Veuillez essayer le nouveau master , ce problème est résolu.

Y aura-t-il une version 0.9.17 qui inclura un correctif pour ce problème ?

@fgnass pouvez-vous le reproduire avec 1.0.0-pre ?

@guille a l' air bien jusqu'à présent ! Je vous ferai savoir si cela se reproduit.

Salut @guille, y a-t-il un moyen d'introduire ce correctif dans la 0.9.16 ? Juste que nous utilisons node.js / socket.io dans un environnement de production bien établi et j'aurai du mal à justifier l'utilisation de versions préliminaires de n'importe quel aspect de notre plate-forme. Si un patch pouvait être fait pour la 0.9.16 ou, si la 1.0.0 devait sortir dans un (très) proche avenir, ce serait de loin préférable.

+1 pour @eggysplat

@aran112000 merci pour la solution heartbeat timeout contournement

En fait, j'ai trouvé la raison pour laquelle j'ai eu ce problème. Très embarrassant, je pensais que j'utilisais la v0.9.16 alors qu'en réalité j'utilisais la v0.9.0 qui avait ce bogue. Il a été corrigé dans la version 0.9.2 par https://github.com/LearnBoost/socket.io/commit/57a0b2406004e46ec34729392ee289191a4f78e7 et https://github.com/LearnBoost/socket.io/commit/df5f23d3091df3bbf296ae296ae952609df3

Veuillez vous assurer que vous n'avez pas de heartbeat interval plus grand que heartbeat timeout comme c'était le cas dans la v0.9.0.

éditant le message afin que d'autres puissent être informés :

perdu quelques heures de suivi des bogues, jusqu'à ce que je décide de tester le problème avec mon mac. Il semble que mon anti-virus sur Windows 8 bloquait également les connexions et provoquait la chute des choses. après l'avoir désinstallé, tout fonctionne bien.

le post pertinent est en fait ici mais assez difficile à trouver.
https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software

Je suis un peu débutant sur socket.io et cela m'a pris plus de deux jours. Après avoir envoyé/reçu des données, le client se déconnecte et se reconnecte de sorte que la valeur socket.id change

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

Enfin, j'ai découvert qu'il y avait une exception dans un rappel afin que socket.io se déconnecte et se reconnecte silencieusement du système.

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
})

Voir aussi ce commentaire

Ainsi, il détecte silencieusement l'erreur et ne m'affiche rien sur la console. Pourquoi supprime-t-il l'erreur et se déconnecte/se reconnecte sans même m'en informer ?

Erreurs 1.3.5 toujours là

Est-ce?

Oui, le problème existe toujours en 1.3.5...

Le problème existe toujours

Oui, le problème persiste dans la version 1.3.5, veuillez le corriger

Je pense qu'il s'agit d'un problème de délai d'attente du client haproxy, comme l'a souligné @citosid . Augmentez le délai d'expiration du client haproxy pour le backend websocket et ce problème devrait être résolu.

J'ai le même problème, mais je n'utilise pas haproxy. Est-ce que quelqu'un connaît la dernière version où cela fonctionnait?

D'accord, je reçois également des rapports indiquant que le problème n'est pas résolu à 100 % dans notre système. Ce qui est amusant, c'est que je pouvais reproduire le problème de manière fiable en définissant "timeout client 1" dans haproxy à une seconde, et rencontrer le bogue dans notre interface.

Poussé par cela, j'ai augmenté le "timeout client" à un plus grand nombre et j'ai pensé que le problème disparaîtrait, car le socket.io keepalive / heartbeat aurait suffisamment de temps pour actualiser la connexion. Cette hypothèse est probablement fausse, et je vous tiendrai au courant si j'apprends plus de choses.

J'ai posté ceci sur un post de stackoverflow et pour certains d'entre vous, cela peut résoudre le problème :
"Il semble que HackTimer.js et ccapture.js remplacent tous les deux window.setTimeout par une fonction personnalisée. HackTimer.js semble fonctionner correctement s'il s'exécute avant tout autre JavaScript. Pour ccapture.js, vous pouvez essayer de vous assurer qu'il est exécuté en tant que premier script. Ainsi, SocketIO utilise d'abord le setTimeout natif de votre navigateur qui est ensuite époustouflé par le setTimeout personnalisé qui interrompt l'un des temporisateurs en cours d'exécution. "

Recherchez votre code pour voir si l'une de vos bibliothèques le remplace :

ag 'window.setTimeout\s*='

Vous pouvez également tester dans votre console pour voir si setTimeout a été modifié :

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

Est-ce que ce bug persiste ? J'ai mis à niveau vers la version principale et tout appareil mobile se déconnecte en 2 minutes environ avec l'avis de fermeture de Transport.

C'est ce que cela a fait bouger de socket.io 1 > et m'a gardé sur socket.io 0.9.17 . Mais maintenant, j'essaie à nouveau, configurez un ping-pong manuellement sur le serveur pour le maintenir en vie et se déconnecte maintenant après 19 minutes.. l'intervalle est toutes les 35 secondes..

Si j'exécute socket.io 0.9.17, ce problème n'est pas présent... mais je ne veux plus l'utiliser car il est obsolète. Toute aide, cela se produit dans le navigateur des appareils mobiles.

@utan quelles sont les étapes de reproduction ?

Salut @rauchg ,

Merci pour votre réponse..

1) Installez socket.io 1.4.0
2) définir la configuration de nginx sur 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) Configurez votre client en utilisant socket.io 1.4.0 / 2015-11-28
4) Connectez-vous dans un appareil mobile.
5) Laissez le navigateur mobile connecté à votre application, puis laissez votre téléphone inactif.

puis les journaux ;

  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

Vous êtes déconnecté au bout de 3 à 4 minutes.

Si vous utilisez l'interrogation, vous obtenez ce journal d'erreurs ;

 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

Alors @rauchg l'a fermé ?

Ne pense vraiment pas que tu devrais.

Je ne l'ai pas fait.

@rauchg ,
Est-ce donc un comportement normal pour socket.io maintenant ? quelque chose a-t-il changé dans le protocole WS qui déconnecte désormais les utilisateurs des appareils mobiles s'ils ne sont pas connectés et qu'ils sont inactifs ?

Je me tape la tête contre le mur avec ce problème, cela ne me laissera pas terminer une mise à niveau... et refactoriser mon code avec le nouveau socket.io...
Mon serveur Ubuntu 10.10
Version Nginx : Nginx/1.8.0
Node v0.10.31 // si je passe à 4.0, c'est la même chose..

en utilisant https et Nginx proxy socket.io ..

Est-ce que quelqu'un d'autre a les mêmes problèmes ou est-ce juste moi ?

Je pense que je pourrais être aussi bien .. très difficile à cerner mon cas cependant. J'utilise sails.js avec socket.io.

Ubuntu 14.04
nœud v5.3.0
npm v 3.3.12
voiles. [email protected]
socket.io@~1.4.3

Mon client est un mélange de socket.io-client et 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){....})

Ainsi, la connexion initiale dure pour toujours... mais après un .emit() ou .broadcast() vers ce client, le serveur vide le client après ~25 secondes à 1min ET..le client n'est pas averti de la déconnexion . Il pense qu'il est toujours connecté.

Très frustrant.

J'ai un problème similaire, mais seulement si j'utilise un socket sécurisé (wss au lieu de ws). Avec ws, tout fonctionne bien, mais avec wss, la connexion est interrompue sporadiquement à des moments aléatoires (~ 15 minutes). Pas de pare-feu, pas de proxy.

Merci @andrin-n-dream Je pense que le mien est également lié au SSL. J'ai une machine Windows en tant que client et ma machine virtuelle Ubuntu (même machine) en tant que serveur. Adaptateur réseau ponté. Je n'ai jamais eu de problèmes avec la connexion réseau générale.

Se produit sur SSL, que j'utilise la terminaison SSL nginx ou sails.js.

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

Courriel envoyé à

Le destinataire a bloqué la réception de votre e-mail.

J'ai débogué pour toujours et je n'ai pas pu trouver d'autre solution pour SSL que de me reconnecter manuellement. Ce serait formidable si engine.io le faisait pour moi et réessaye lorsque le transport est fermé.

y a-t-il une solution pour cela? J'ai exactement le même problème. après quelques secondes, j'obtiens un délai d'attente de pulsation dans le journal de débogage du serveur mais le client pense toujours qu'il est connecté.

Eh bien, en raison d'autres problèmes urgents, j'ai mis à niveau mon environnement et c'est maintenant en veilleuse. Ce serait bien de voir si le nœud 6.5.0 fait une différence. Sails.js a mis à jour certains packages et modifié son utilisation de ces fonctions de bas niveau...

Je n'ai tout simplement pas le temps de m'y replonger pour le moment, car je migre une quantité massive de C++ hérité. Peut-être plus tard cette année ou en janvier.

cela se produit toujours sur 2.0.3 ...
https://github.com/socketio/socket.io/issues/3025

sans solution de contournement, socket.io est fondamentalement inutilisable car 25% de vos clients vont avoir ce problème.

io.set('délai de pulsation', 99999);

@Aaron1011 S'agit-il d'un code côté serveur ou client ? S'il s'agit de son côté serveur, faut-il modifier quelque chose du côté client ?

A essayé:
io.set('délai de pulsation', 99999);
Côté serveur et n'a pas résolu le problème en utilisant socket.io v 2.0.3. Je vais essayer de rétrograder à 0.8.6 ensuite.

Impossible de passer à 0.8.6 car il s'agit effectivement d'un énorme terrier de lapin. Toute la syntaxe a changé et comme il n'y a pas de documentation que j'ai pu trouver sur la 0.8.6, c'est une cause perdue. Je n'ai vraiment pas envie de réécrire mon application pour revenir à une ancienne version dans l'espoir que cela puisse résoudre ce problème.

Est-ce que n'importe qui a des idées/correctifs pour v2.03 ? Choses que j'ai essayé:

• définissez pingInterval sur 9999999
• définir pingTimeout sur 99999999
• envoyer des messages automatiquement comme un keep-alive. J'envoie un message toutes les secondes, mais j'obtiens toujours les déconnexions aléatoires.
• Pare-feu désactivé
• Essayé avec l'interrogation XHR activée/désactivée
• Changement de port de quelque chose d'aléatoire à 80

Je suis sûr que ce n'est pas une erreur de codage mais c'est spécifique au PC car cela arrive sur certains et pas sur d'autres. Cela pourrait avoir quelque chose à voir avec l'adaptateur réseau.

@forgeableSun vous devriez écrire votre application basée sur Primus, j'ai refactorisé mon application avec primus et j'utilise actuellement socketJs avec elle.

Prend en charge un autre projet, pas besoin de changer de code pour utiliser un autre projet en temps réel.

Salutations.

@utan j'adorerais l' essayer. mais comment puis-je passer de socket.io exactement avec une ligne de code ? Il ne semble pas y avoir d'exemples sur le passage d'autres frameworks.

npm install browserchannel --save

var primus = new Primus(server, { transformer: 'browserchannel' });

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

L'espoir aide.

qu'est-ce que le canal du navigateur a à voir avec socket.io ?

C'est juste un exemple de comment passer à un autre framework.

Comme tu m'as demandé un exemple..

d'accord, mais socket.io n'est même pas répertorié comme l'un des frameworks en temps réel pris en charge. ce n'est jamais juste 1 ligne de code pour changer d'API, je ne vois pas comment les docs peuvent annoncer cela sans donner d'exemples.

Écoutez, socket.io est bogué après > = 1, il a des déconnexions étranges, je suggère d'utiliser primus pour que vous puissiez passer à un autre framework.

C'est pourquoi je vous ai donné un exemple, bien sûr, vous devrez refactoriser le code pour utiliser primus, puis après vous serez libre d'essayer différents frameworks pour voir lequel vous convient le mieux ou si l'on casse, utilisez-en un autre.

Salutations

@utan Je vois, je pensais que c'était un transformateur pour passer d'un framework à un autre avec l'intégralité de l'application écrite dans ce framework (comme un adaptateur). Mais vraiment, c'est un transformateur pour passer en toute transparence aux frameworks avec l'intégralité de l'application écrite en primus.

En effet, vous m'avez remonté la tête.. je ne suis pas aussi compétent pour faire la différence, je pensais que nous parlions de la même chose..

Salutations.

Mes journaux de serveur :
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »
déconnexion du client. Raison de la déconnexion : « fermeture du transport »

Passé à ws (https://github.com/websockets/ws) qui impliquait des réécritures massives, mais j'utilise maintenant l'objet navigateur websocket natif du côté client et tout fonctionne parfaitement. Je n'ai plus le problème. Adieu socket.io !

J'avais des déconnexions aléatoires après 10 à 30 minutes. J'ai rappelé que mon service d'hébergement exécute NodeJS avec Passenger sur un serveur partagé Apache. Je ne le comprends pas vraiment, mais fondamentalement, il est censé y avoir des problèmes avec les Websockets dans ce type d'intégration. Je teste avec les transports de configuration : ['polling'] uniquement, tandis que sur l'hôte local, je fonctionne avec les transports : ['websockets', 'polling'] sans erreurs ni interruptions. Jusqu'ici tout va bien après 30min...