Socket.io: Unerklärtes Trennen von 'Transportende' nach dem Upgrade

0.9.1 könnte einen Fehler mit Herzschlägen eingeführt haben, die vorzeitige Verbindungsabbrüche auslösten.
Ich schaue mir das an und könnte morgen eine 0.9.2 haben

Dito. Wiederholte Trennungen/Wiederherstellungen von Verbindungen in Chrome und FF auf Mac, Client und Server auf demselben Computer.
Leicht zu erkennen an den socket.io-Beispielen in der Readme, Standardeinstellungen unverändert.

Habe das gleiche Problem ... Mir ist auch aufgefallen, dass unmittelbar nach dem Trennen des Sockets ein neuer Socket instanziiert wurde.

Problemumgehung für mich bestand darin, das Zeitlimit für das Schließen manuell festzulegen:

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

Dieses Problem hatte ich auch. Danke steffenwt für die Problemumgehung.

Ja diesen Fehler habe ich auch. Ich habe vor ein paar Tagen angefangen, socket.io zu lernen und dachte zuerst, ich mache etwas falsch.

Ein Downgrade auf 0.9.0 funktioniert.

Ich bin mir nicht sicher, ob es relevant ist, aber der Socket wird bei jedem zweiten Herzschlag geschlossen. Also geht das so

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

Melden Sie sich hier an:

   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

ich habe das Problem auch.

Ich verwende 0,91-1 .

Ich versuche es, habe aber dieses Problem.

io.configure(funktion() {
io.set('Zeitüberschreitung beim Schließen', 60_60_24); // 24h Auszeit
});

selbes Problem hier

Hast du ein Downgrade auf 0.9.0 gemacht? Ich habe es jetzt auf NPM als neuestes markiert

gleiches Problem hier für 0.9.1-1, nur auf 0.9.0 herabgestuft, und das Problem ist weg.

Als Workaround können Sie einige Keep-Alives vom Client senden, sagen wir 20 Sekunden lang und diese sofort vom Server beantworten:

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

FWIW: Wenn Sie den Client von einem anderen Server aus bedienen und Ihr Clientcode nicht auf 0.9.0 herabgestuft wurde, wird das Problem weiterhin auftreten.

Ich habe 'socket.io' auf 0.9.0 herabgestuft und habe das Problem immer noch gesehen. Dann habe ich socket.io-client auf 0.9.0 heruntergestuft und ich bekomme die Trennung nicht.

Außerdem sind die Transporte, die ich versucht habe, die fehlschlagen, Web-Sockets und xhr-Polling.

Dieses Problem sollte geschlossen werden, oder?

Ich habe das gleiche Problem. Aber ich habe gemerkt, dass es daran liegt, dass ich Haproxy habe.

Mein Problem ist hier:

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

Direkt in der Zeile "timeout client 1000" (ich habe es auf 1 Sekunde geändert, um zu sehen, ob es das Problem war, und es war ...).

Also suche ich jetzt, ob es eine Möglichkeit gibt, es nur für die Websocket-Backends zu ändern.

Ich hoffe das hilft jemandem :+1:

Zu Ihrer Information, ich sehe dieses Problem auch immer noch mit xhr-polling und 0.9.14. Alle 25 Sekunden wird die Verbindung erzwungen. Protokoll ist identisch mit oben.

Ich kann auch überprüfen, dass dies mit 0.9.14-Server und 0.9-Client geschieht. Obwohl die Verbindung nicht alle 25 Sekunden getrennt wird, wird die Verbindung zeitweise getrennt. Ich habe es auf einen Aufruf zurückgeführt stream.emit('end'); in node.js' _stream_readable.js. Ich denke, es ist ein Ergebnis des Lesens von EOF im Puffer.

@citosid warum sollte dies durch eine Zeitüberschreitung des Haproxy-Clients verursacht werden?

Passiert mit 0.9.16. Gleiches wie bei BoarK

Ist der Socket.io-Support tot?

@joefaron Es muss Unterstützung geben, bevor es sterben kann. Also nein, die Socket.IO-Unterstützung ist nicht tot, sie hat einfach nie existiert.

Gleiches Problem hier mit Socket.io 0.9.16 - Verbindungen werden alle ~25 Sekunden unterbrochen und Protokolle zeigen gleichzeitig "Verwerfen des Transports" an.

Das Downgrade auf 0.8.6 hat im Grunde alles für mich behoben.. und ich benutze
jsonp-polling statt xhr-polling als Backup zum Websocket.. scheint weit entfernt
stabiler.

Am Sonntag, 26. Januar 2014 um 10:16 Uhr schrieb Aran Reeks [email protected] :

Gleiches Problem hier mit Socket.io 0.9.16 - Verbindungen werden alle ~25 . unterbrochen
Sekunden und Protokolle, die gleichzeitig "Transport verwerfen" anzeigen.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/LearnBoost/socket.io/issues/777#issuecomment -33325205
.

Hallo @joefaron ,

Ich habe heute Abend ein wenig mit den verschiedenen Konfigurationsoptionen herumgespielt und werde mich morgen weiter damit befassen, aber ich kann bestätigen, dass das Problem darin besteht, dass die Heartbeat-Prüfungen fehlschlagen. Diese Prüfungen sind vorhanden, um sicherzustellen, dass Verbindungen zu einem Benutzer weiterhin erforderlich sind und dieser nicht verlassen hat, ohne aus irgendeinem Grund eine Trennung zu senden.

Ich konnte diesen Fehler sowohl in Firefox als auch in der aktuellen stabilen Version von Chrome (32.0.1700.76 m) replizieren.

Anfangs habe ich versucht, Heartbeats vollständig zu deaktivieren, da sie für unsere Anwendung nicht wirklich erforderlich waren. Dies kann wie folgt erfolgen (laut den aktuellen Dokumenten, obwohl es bei meinem Versuch alle Transportmethoden zu entfernen schien und ständig endete) Absturz und Neustart).
io.set('heartbeats', false);

Da dies fehlschlug, bestand mein nächster Versuch darin, das Timeout zwischen Heartbeat-Anfragen zu erhöhen, was mithilfe der folgenden Schritte in Ihrer app.js erfolgen kann:
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

Dies hat sich für unsere Anwendung bewährt, da wir uns nicht um Client-Trennungen kümmern, dies ist jedoch möglicherweise keine praktikable Option in Ihrer Umgebung.

Für alle anderen mit diesem Problem, falls es hilft, ist meine Umgebung wie folgt:
NodeJS: v0.10.24 Socket.io: v0.9.16 Centos 6.5

Ich denke, dies ist ein wirklich dringendes / kritisches Thema. Warum wurde es noch nicht gelöst? Seit dem Start dieses Thementhreads sind zwei Jahre vergangen.

Ich habe auch dieses Problem:

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

d-oliveros: Ich empfehle dringend ein Downgrade auf 0.8.6. das hatte ich noch nicht
Problem.. und ich glaube nicht, dass der neueste Build in naher Zukunft behoben wird.

Am Samstag, den 15. Februar 2014 um 20:55 Uhr schrieb d-oliveros [email protected] :

Ich denke, dies ist ein wirklich dringendes / kritisches Thema. Warum war es nicht
schon gelöst? Seit dem Start dieses Thementhreads sind zwei Jahre vergangen.

Ich habe auch dieses Problem:

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

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/LearnBoost/socket.io/issues/777#issuecomment -35177466
.

Bitte versuchen Sie es mit dem neuen master , dieses Problem ist behoben.

Wird es eine Version 0.9.17 geben, die eine Lösung für dieses Problem enthält?

@fgnass kannst du es mit 1.0.0-pre reproduzieren?

@guille sieht soweit gut aus! Ich melde mich, wenn es jemals wieder passiert.

Hallo @guille, gibt es eine Möglichkeit, diesen Fix in 0.9.16 einzuführen? Nur, dass wir node.js / socket.io in einer gut etablierten Produktionsumgebung verwenden und es mir schwer fallen wird, die Verwendung von Vorabversionen aller Aspekte unserer Plattform zu rechtfertigen. Wenn ein Patch für 0.9.16 erstellt werden könnte oder wenn 1.0.0 in (sehr) naher Zukunft veröffentlicht werden soll, wäre dies weitaus vorzuziehen.

+1 für @eggysplat

@aran112000 danke für die heartbeat timeout Problemumgehung. Funktioniert bei mir auf v0.9.16.

Tatsächlich habe ich den Grund für dieses Problem gefunden. Sehr peinlich, ich dachte, ich würde v0.9.16 verwenden, obwohl ich in Wirklichkeit v0.9.0 benutzte, das diesen Fehler hatte. Es wurde in v0.9.2 von https://github.com/LearnBoost/socket.io/commit/57a0b2406004e46ec34729392ee289191a4f78e7 und https://github.com/LearnBoost/socket.io/commit/df5f23d3091df3bbf296a9526be28

Bitte stellen Sie sicher, dass heartbeat interval größer als heartbeat timeout wie es in v0.9.0 war.

Bearbeiten des Beitrags, damit andere darauf aufmerksam gemacht werden:

Ich habe ein paar Stunden Bugtracking verschwendet, bis ich beschloss, das Problem mit meinem Mac zu testen. Es scheint, als ob mein Antivirenprogramm unter Windows 8 auch die Verbindungen blockiert und Dinge abbricht. Nach der Deinstallation funktioniert alles einwandfrei.

relevanter Beitrag ist eigentlich hier aber recht schwer zu finden.
https://github.com/LearnBoost/socket.io/wiki/Socket.IO-and-firewall-software

Ich bin sozusagen der Anfänger von socket.io und das hat mehr als zwei Tage gedauert. Nach dem Senden/Empfangen von Daten trennt der Client die Verbindung und stellt die Verbindung wieder her, sodass sich der Wert von socket.id ändert

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

Schließlich habe ich festgestellt, dass es innerhalb eines Callbacks eine Ausnahme gibt, sodass socket.io still die Verbindung zum System trennt und wieder verbindet.

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

Siehe auch diesen Kommentar

Es fängt also stillschweigend Fehler ab und zeigt mir nichts auf der Konsole an. Warum wird der Fehler unterdrückt und die Verbindung getrennt/wieder hergestellt, ohne mich überhaupt zu benachrichtigen?

1.3.5 Fehler immer noch vorhanden

Ist es?

Ja, das Problem besteht noch in 1.3.5...

Problem besteht immer noch

Ja, das Problem tritt immer noch in 1.3.5 auf, bitte beheben

Ich denke, dies ist ein Problem mit der Zeitüberschreitung des Haproxy-Clients, wie @citosid darauf hingewiesen hat. Erhöhen Sie das Timeout des Haproxy-Clients für das Websocket-Backend und dieses Problem sollte behoben sein.

Ich habe das gleiche Problem, aber ich benutze kein Haproxy. Kennt jemand die letzte Version, bei der das funktioniert hat?

Okay, ich bekomme auch Berichte, dass das Problem in unserem System nicht zu 100% behoben ist. Komisch ist, dass ich das Problem zuverlässig reproduzieren konnte, indem ich "timeout client 1" in haproxy auf eine Sekunde setzte und den Fehler in unserem Frontend erlebte.

Daraufhin habe ich "timeout client" auf eine größere Zahl erhöht und dachte, das Problem würde verschwinden, da das socket.io-Keepalive / Heartbeat genug Zeit hätte, um die Verbindung zu aktualisieren. Diese Annahme ist höchstwahrscheinlich falsch, und ich werde euch auf dem Laufenden halten, wenn ich mehr herausfinde.

Ich habe dies in einem Stackoverflow- Beitrag gepostet und für einige von euch kann dies das Problem lösen:
"Es scheint, dass HackTimer.js und ccapture.js beide window.setTimeout durch eine benutzerdefinierte Funktion ersetzen. HackTimer.js scheint in Ordnung zu sein, wenn es vor jedem anderen JavaScript ausgeführt wird. Für ccapture.js sollten Sie versuchen, sicherzustellen, dass dies der Fall ist Als erstes Skript ausführen. SocketIO verwendet also zuerst das native setTimeout Ihres Browsers, das dann vom benutzerdefinierten setTimeout weggeblasen wird, das jeden der derzeit laufenden Timer unterbricht."

Durchsuchen Sie Ihren Code, um zu sehen, ob eine Ihrer Bibliotheken ihn ersetzt:

ag 'window.setTimeout\s*='

Sie können auch in Ihrer Konsole testen, ob setTimeout überhaupt geändert wurde:

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

Besteht dieser Fehler immer noch? Ich habe ein Upgrade auf die Master-Version durchgeführt und jedes Mobilgerät trennt sich in etwa 2 Minuten mit der Benachrichtigung "Transport schließen".

Das war es, was es von socket.io 1 > herrührte und mich auf socket.io 0.9.17 hielt. Aber jetzt versuche ich es noch einmal, setze manuell ein Ping-Pong auf dem Server, um es am Leben zu halten und trenne jetzt nach 19 Minuten die Verbindung.. das Intervall ist alle 35 Sekunden..

Wenn ich socket.io 0.9.17 ausführe, ist dieses Problem nicht vorhanden.. aber ich möchte es nicht mehr verwenden, da es veraltet ist. Jede Hilfe, dies geschieht im Browser in mobilen Geräten.

@utan was sind die Reproduktionsschritte?

Hallo @rauchg ,

Danke für deine Antwort..

1) installiere socket.io 1.4.0
2) setze nginx config auf 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) Setzen Sie Ihren Client mit socket.io 1.4.0 / 2015-11-28
4) Verbinden Sie sich mit einem Mobilgerät..
5) Lassen Sie den mobilen Browser mit Ihrer App verbunden und lassen Sie dann Ihr Telefon im Leerlauf.

dann Protokolle;

  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

Die Verbindung wird nach 3 4 Minuten getrennt.

Wenn Sie Polling verwenden, erhalten Sie dieses Fehlerprotokoll;

 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

Also hat @rauchg es geschlossen?

Denke wirklich nicht, dass du das solltest.

Ich nicht.

@rauchg ,
Ist das jetzt ein normales Verhalten für socket.io? hat sich etwas im WS-Protokoll geändert, das jetzt Benutzer in mobilen Geräten trennt, wenn sie nicht eingesteckt sind und sie im Leerlauf sind?

Ich schlage meinen Kopf mit diesem Problem gegen die Wand, es lässt mich kein Upgrade abschließen... und meinen Code mit neuem socket.io umgestalten...
Mein Server Ubuntu 10.10
Nginx-Version: Nginx/1.8.0
Node v0.10.31 // Wenn ich auf 4.0 aktualisiere, ist dasselbe.

mit https und Nginx proxing socket.io..

Hat noch jemand die gleichen Probleme oder bin ich nur?

Ich denke, ich könnte genauso gut sein... es ist jedoch sehr schwierig, meinen Fall zu lokalisieren. Ich verwende sails.js mit socket.io.

ubuntu 14.04
Knoten v5.3.0
npm v 3.3.12
Segel. [email protected]
socket.io@~1.4.3

Mein Client ist eine Mischung aus socket.io-client und 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){....})

Die anfängliche Verbindung dauert also ewig...aber dann nach einer .emit() oder .broadcast() zu diesem Client, dumpt der Server den Client nach ~25 Sekunden bis 1min UND..der Client wird nicht über die Trennung benachrichtigt . Es denkt, es ist immer noch verbunden.

Sehr frustrierend.

Ich habe ein ähnliches Problem, aber nur, wenn ich einen sicheren Socket verwende (wss statt ws). Mit ws funktioniert alles gut, aber mit wss wird die Verbindung sporadisch zu zufälligen Zeiten (~15 Minuten) unterbrochen. Keine Firewalls, keine Proxys.

Danke @andrin-n-dream Ich denke, meins hängt auch mit SSL zusammen. Ich habe eine Windows-Maschine als Client und meine Ubuntu-VM (gleiche Maschine) als Server. Überbrückter Netzwerkadapter. Hatte noch nie Probleme mit der allgemeinen Netzwerkverbindung.

Passiert bei SSL, unabhängig davon, ob ich nginx SSL oder sails.js SSL-Terminierung verwende.

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

E-Mail an

Der Empfänger hat den Empfang Ihrer E-Mail blockiert.

Ich habe ewig debuggt und konnte keine andere Lösung für SSL finden, als die Verbindung manuell neu zu verbinden. Wäre toll, wenn engine.io dies für mich tun und es erneut versuchen würde, wenn der Transport geschlossen ist.

gibt es dafür eine lösung? ich habe genau das gleiche problem. Nach ein paar Sekunden erhalte ich eine Heartbeat-Zeitüberschreitung im Debug-Log vom Server, aber der Client denkt immer noch, dass er verbunden ist.

Nun, aufgrund anderer dringender Probleme habe ich meine Umgebung aufgerüstet und dies ist jetzt auf dem Rückzug. Wäre schön zu sehen, ob Knoten 6.5.0 einen Unterschied macht. Sails.js hat einige Pakete aktualisiert und die Verwendung dieser Low-Level-Funktionen geändert...

Ich habe gerade keine Zeit, mich damit noch einmal zu befassen, da ich eine riesige Menge an altem C++ migriere. Vielleicht noch dieses Jahr oder Januar.

das passiert immer noch auf 2.0.3 ...
https://github.com/socketio/socket.io/issues/3025

Ohne einen Workaround ist socket.io im Grunde unbrauchbar, da 25% Ihrer Kunden dieses Problem haben werden.

io.set('Heartbeat-Timeout', 99999);

@ Aaron1011 Ist dies serverseitiger oder clientseitiger Code? Wenn auf der Serverseite, muss auf der Clientseite etwas geändert werden?

Versucht:
io.set('Heartbeat-Timeout', 99999);
Auf der Serverseite und das Problem mit socket.io v 2.0.3 nicht behoben. Werde als nächstes versuchen, auf 0.8.6 herunterzustufen.

Konnte nicht auf 0.8.6 herabgestuft werden, da es sich tatsächlich um ein massives Kaninchenloch handelt. Die gesamte Syntax hat sich geändert und da ich keine Dokumentation zu 0.8.6 finden konnte, ist dies eine verlorene Sache. Ich habe wirklich keine Lust, meine App umzuschreiben, um auf eine alte Version herunterzustufen, in der Hoffnung, dass dieses Problem dadurch behoben wird.

Hat jemand irgendwelche Ideen/Fixes für v2.03? Dinge die ich probiert habe:

• setze pingInterval auf 9999999
• setze pingTimeout auf 99999999
• Senden von Nachrichten automatisch als Keep-Alive. Ich sende alle 1 Sekunde eine Nachricht, erhalte aber immer noch die zufälligen Verbindungsabbrüche.
• Deaktivierte Firewall
• Versucht mit XHR Polling ein/aus
• Port von zufällig auf 80 . geändert

Ich bin mir sicher, dass es sich nicht um einen Codierungsfehler handelt, sondern PC-spezifisch ist, da dies bei einigen und bei anderen nicht der Fall ist. Es könnte etwas mit dem Netzwerkadapter zu tun haben.

@forgeableSun Sie sollten

Unterstützen Sie ein anderes Projekt, ohne dass der Code in einem anderen geändert werden muss, um ein anderes Echtzeitprojekt zu verwenden.

Grüße.

@utan Ich würde es gerne ausprobieren. aber wie genau wechsle ich von socket.io mit einer Codezeile? Es scheint keine Beispiele für den Wechsel von anderen Frameworks zu geben.

npm install browserchannel --save

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

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

Hoffnung hilft.

Was hat der Browserkanal mit socket.io zu tun?

Das ist nur ein Beispiel für den Wechsel zu einem anderen Framework.

Wie Sie nach einem Beispiel gefragt haben..

okay, aber socket.io wird nicht einmal als eines der unterstützten Echtzeit-Frameworks aufgeführt. Es ist nie nur eine Codezeile, um APIs zu wechseln. Ich sehe nicht, wie die Dokumente dies bewerben können, ohne Beispiele zu nennen.

Hören Sie, socket.io ist nach >= 1 fehlerhaft. Es hat seltsame Verbindungsabbrüche. Ich schlage vor, Primus zu verwenden, damit Sie zu einem anderen Framework wechseln können.

Aus diesem Grund habe ich Ihnen ein Beispiel gegeben. Natürlich müssen Sie den Code umgestalten, um Primus zu verwenden.

Grüße

@utan Ich sehe, ich dachte, es wäre ein Transformer für den Wechsel von einem Framework zu einem anderen, wobei die gesamte App in diesem Framework geschrieben ist (wie ein Adapter). Aber wirklich, es ist ein Transformer für den nahtlosen Wechsel zu Frameworks, wobei die gesamte App in Primus geschrieben ist.

In der Tat, du bist mir in den Kopf gegangen.. Ich kenne den Unterschied nicht so gut, dachte, wir sprachen über dasselbe..

Grüße.

Meine Server-Logs:
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"
Client trennen. Trennungsgrund: "Transport nah"

Wechsel zu ws (https://github.com/websockets/ws), was massive Umschreibungen mit sich brachte, aber ich verwende jetzt das native Websocket-Browserobjekt auf der Clientseite und alles funktioniert perfekt. Ich habe das Problem nicht mehr. So lange socket.io!

Ich hatte nach 10 bis 30 Minuten zufällige Verbindungsabbrüche. Ich erinnerte mich daran, dass mein Hosting-Dienst NodeJS mit Passenger auf einem gemeinsam genutzten Apache-Server ausführt. Ich verstehe es nicht wirklich, aber grundsätzlich soll es bei dieser Art der Integration Probleme mit Websockets geben. Ich teste mit set transports: ['polling'] only, während ich auf dem localhost mit transports: ['websockets', 'polling'] ohne Fehler und Aussetzer laufe. Soweit so gut nach 30min...