Socket.io: Kontinuierlicher „Transport nah“ am Kunden

Gibt es Neuigkeiten zu diesem Problem, da ich genau das gleiche Problem habe!

Ich habe das gleiche Problem auch, wenn ich k8ns bereitstelle, aber wenn ich lokal ausführe, funktioniert es einwandfrei.

ich leide auch darunter...

@talas9 @muhammadnasr @htamop die allgemeinen Fragen, um das Problem debuggen / reproduzieren zu können:

• welche Version des Clients/Servers verwendest du?
• welcher browser?
• Ist das mit der Geige reproduzierbar?

Vielen Dank!

Ich habe es mit 2.1.0 und 2.0.4 Client und Server probiert. Auf Chrom und Safari (neueste).
Wenn ich lokal ausführe, funktioniert es einwandfrei (kann über eine Stunde lang ohne Trennung verbunden werden), aber wenn ich K8ns hinter dem Ingress-Loadbalancer bereitstelle, tritt dieses Problem auf ...

Zu Ihrer Information wird die Verbindung jedes Mal genau nach 25 Sekunden geschlossen, siehe Screenshot

@talas9 @htamop @dnwldbs84 verwenden Sie einen Load Balancer?

@darrachequesne Welche(n) Load-Balancer empfehlen Sie, mit socket.io zu verwenden?

@muhammadnasr @darrachequesne
Ich habe den 2.1.0-Server und den 1.0.0-Client (Android) verwendet.
Ich muss die Verbindung 8 bis 9 Stunden lang stabil halten, aber sie wird unerwartet getrennt.
Ich habe beide Versionen auf 1.7.4 und 0.8.3 geändert? nach anderen Lösungspost. Ich werde morgen mal testen ob es gut funktioniert

Ich hatte keinen Load Balancer verwendet. Sowohl der Client als auch der Server verwendeten die Version 2.0.3 von Socket.io (ich kann mich nicht an alle Versionen erinnern, die ich verwendet habe). Ich weiß nicht, welcher Browser das Problem verursacht. Die meisten Benutzer haben jedoch Chrome verwendet. In meinem Fall war die Trennung zufällig, so dass sie sich nicht reproduzieren kann.
Und ich wechselte zu ws. Ich bin mir nicht sicher, ob das Problem gelöst ist.

@muhammadnasr @darrachequesne @dnwldbs84
Ich denke, in meinem Fall ist es gelöst.
Ich verwende 0.8.3 socket.io-client im Android-Vordergrunddienst (api 26) und die Version 1.3.5 im nodejs-Server.
Das Problem kann jedoch nicht an der Version liegen.
Ich habe pingInterval im Server auf 10 ms geändert und es scheint ordnungsgemäß zu funktionieren (Ping-Timeout und Transportabschluss sind nicht aufgetreten)
var io = require('socket.io')(http, {pingInterval: 10, pingTimeout: 4000 });

10 Millisekunden sind zu eng, dadurch wird das Netzwerk überlastet.

10 Millisekunden sind zu eng, dadurch wird das Netzwerk überfordert.

Richtig!

@muhammadnasr jeder Load-Balancer sollte funktionieren. Bitte sehen Sie sich die folgenden Beispiele an:

• 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 ist jedoch erforderlich, wenn Sie Polling aktivieren (was die Standardeinstellung ist).

@darrachequesne Ich habe das gleiche Problem, nach 8 ~ 9 Stunden trennt sich die Steckdose mit dem Grund "Transport in der Nähe"

Ich benutze:

Chrome: 61.0.3163.100
Electron: 2.0.2
Socket.io: 2.1.1

Hatte das gleiche Problem, konnte es mit CDN aus diesem Kommentar https://github.com/socketio/socket.io/issues/3025#issuecomment -329024833 beheben und Timeout und Intervall wie folgt einstellen:

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

Hey,
Wir haben das gleiche Problem mit socket.io, wenn es unter Kubernetes und NGINX Ingress Controller ausgeführt wird.
Wenn die nginx-Konfiguration neu geladen wird, wird der Prozess neu erstellt und die gesamte vorhandene Kommunikation wird gelöscht, was zu transport close führte. Alle anderen Bereitstellungen, die den Ingress-Controller verwenden, können das erneute Laden der Konfiguration verursachen

Erstmal vielen Dank für dieses tolle Projekt.

Gleiches Thema hier, vielleicht bringe ich dir etwas Neues.

Ich habe einen ws-Server und einen ws-Client auf dem Knoten js.
Dieser ws-Client wird von einer Knoten-js-App verwendet, in der sich ein Dienst (Mikrodienst) befindet.

Andere ws-Clients von Webbrowsern (von Client-Apps) kommunizieren über den ws-Server mit diesem Knoten-js-Dienst.

Alles funktioniert wie erwartet.

Bei Stresstests jetzt (10 Clients fragen intensiv nach Daten), am Ende der Tests, wenn alle Jobs und Transaktionen abgeschlossen sind, wird die Verbindung des Dienstes mit Fehler "transport close" geschlossen. Dies geschieht nicht immer.

Dies ist die Konfiguration des Servers:
pingTimeout: 15000,
pingIntervall: 20000,
Es sieht so aus, als ob während der hohen Last einige Pings verloren gehen ...? oder ich weiß es nicht.
Ist das etwas, was ich erwarten sollte?

Auch mit der Standardkonfiguration pingTimeout: 2000 erhielt ich diesen Fehler mitten im Stresstest. Dies war ebenfalls völlig unerwartet, aber nehmen wir an, der Server war überlastet und konnte nicht innerhalb von 2 Sekunden (!) antworten und wir könnten diesen Fehler erhalten. Aber jetzt mit pingTimeout: 15000 passiert es fast 50% und erst nach dem Ende der Tests.

Hmho, ich glaube, die Microservices sollten mit dieser Art von Fehlern rechnen, selbst wenn sie auf demselben LAN laufen, aber die Frage ist, warum passiert das?

Ich habe versucht, ein kleines Setup zu erstellen, um dieses Problem zu reproduzieren, aber ich konnte es nicht schaffen.

Wie aktiviert man die Protokolle? das DEBUG=socket.io* funktioniert nicht. Obwohl die Variable gesetzt ist, bekomme ich keine Ausgabe.

Ich glaube fest daran, dass dies mit #2924 zusammenhängt.
Die Wiederverbindung auf einem Client wird durch einige Browser (Safari und Chrome) verursacht, die Timer für inaktive Tabs drosseln, um Batterie zu sparen.
Dies führt zu verzögerten Heartbeat-Meldungen vom Client und vom Server, die die Verbindung aufgrund von pingTimeout schließen.
Das Erhöhen von pingTimeout funktioniert bis zu einem gewissen Grad, aber ich erhalte immer noch Reconnects in einer Produktionsumgebung.

Ich habe das gleiche Problem auch, wenn ich k8ns bereitstelle, aber wenn ich lokal ausführe, funktioniert es einwandfrei.

@muhammadnasr wo können Sie das Bereitstellungsproblem auf K8s überwinden? Ich habe ähnliche Probleme.

@bheema01 Stellen Sie einfach sicher, dass Sie Stickysession auf Ihrem Proxy/Loadbalancer aktiviert haben und es sollte funktionieren

Habe den gleichen Fehler

Gleiches Problem .....Clients verbinden und trennen wiederholt die Verbindung, wenn sich der serverseitige Socket-Endpunkt hinter einem Load Balancer befindet. Auch nach der Konfiguration von Sticky Sessions besteht das Problem weiterhin. @muhammadnasr konnten Sie das Problem lösen.

Ich habe diesen Fehler gesehen, wenn der Thread häufig länger als 200ms blockiert wurde.
Wenn dies häufig vorkommt, ist dies schlecht für socket.io _und auch für Ihre App_.
Das socket.io hat ein Timeout, um den Heartbeat der Verbindung zu überprüfen.
Wenn dieses Timeout überschritten wird, wird die Verbindung beendet und wir erhalten diesen Fehler.

@varunSabnis Nach dem

@dennisat Ich habe versucht zu überprüfen, wie lange es dauerte, bis mein Kunde ein Pong-Paket erhielt. Jedes Mal waren es über 200ms, was sowohl mit Socket-Server in der Cloud als auch mit Socket-Server auf meinem localhost getestet wurde. Das lokale Setup trennt den Socket nicht (alles funktioniert einwandfrei), während der Socket im Cloud-Setup ständig eine Verbindung herstellt und trennt. Also ich glaube nicht, dass das das Problem ist.
@muhammadnasr okay, das ist großartig. Habe es tatsächlich aktiviert, aber immer noch einige Probleme.

@muhammadnasr @darrachequesne @dnwldbs84
Ich denke, in meinem Fall ist es gelöst.
Ich verwende 0.8.3 socket.io-client im Android-Vordergrunddienst (api 26) und die Version 1.3.5 im nodejs-Server.
Das Problem kann jedoch nicht an der Version liegen.
Ich habe pingInterval im Server auf 10 ms geändert und es scheint ordnungsgemäß zu funktionieren (Ping-Timeout und Transportabschluss sind nicht aufgetreten)
var io = require('socket.io')(http, {pingInterval: 10, pingTimeout: 4000 });

Es funktioniert magisch, danke!!!!!!!

Ich finde, dass ich jedes Ping-Intervall "transportnah" habe.

Ich hatte dieses Problem wirklich satt.
Ich denke, Sie sollten die Version von "socket.io" mit "socket.io-client" überprüfen.
Wenn die Server-/Client-Version nicht übereinstimmt, war die Verbindung sehr instabil.

Ich empfehle, einfach CDN wie unten für den Client zu verwenden.