Als schnellen Hack können Sie "Neue Verbindung erzwingen" verwenden: falsche Konfiguration

Ich habe diesen Fehler auch in unserer Anwendung beobachtet.
Fortpflanzung war als nächstes. In FF mit Websocket-Verbindung ist ein Fehler aufgetreten. Dann hatten nacheinander 3 Wiederverbindungsereignisse generiert. Danach wurden 3 neue Verbindungen hergestellt und der Browser erhielt 3 Nachrichten anstelle von einer.

Vielleicht ein Fehler in der Wiederverbindungslogik? Etwas, das mehrere Wiederverbindungen anstelle einer erzeugt.

Ich habe Probleme in älteren Browsern gesehen, die keine Websockets unterstützen (z. B. FF 3.6), bei denen das Initialisieren von socket.io im dom ready-Ereignis ("$ ()" in jQuery) mehrere Verbindungen verursacht, während das Initialisieren im späteren window.load Ereignis nicht. Ich habe festgestellt, dass dieses spezielle Problem durchweg reproduzierbar ist. Ich bin mir nicht sicher, ob es dasselbe ist, das Sie sehen, aber die Symptome sehen sehr ähnlich aus.

Gleiches Problem auch hier. Problem ist, wenn der Server aus irgendeinem Grund abstürzt und dann wieder eingeschaltet wird, führt die erneute Verbindung jedes Mal zu n + 1 Antworten. Wenn wir also sagen, dass 3 Server abstürzen, gehen auf jedem Server 4 Antworten ein. Durch das Aktualisieren der Seite wird das Problem behoben. Hat jemand eine Lösung dafür gefunden [auch wenn es nur vorübergehend ist?]

Dies ist möglicherweise keine dauerhafte Lösung, aber ich habe meinen Code neu angeordnet, sodass jedes Ereignis unabhängig gebunden ist und das Problem der Duplizierung bei der automatischen erneuten Verbindung behoben zu sein scheint

me.socket.on('connect', function () {
});

me.socket.on('message', function(data) {

});

me.socket.on('disconnect', function() {

});

Nach einer Woche Debuggen über einen gefangenen Wireshark-Dump habe ich es geschafft, den Grund zu finden und diesen Fehler zu reproduzieren.

Kurz gesagt, die Wiederverbindungslogik ist sehr fragil. Dies hängt von vielen Timern ab, die parallel ausgeführt werden können, und führt zu mehreren erneuten Verbindungen. Diese Zeile https://github.com/LearnBoost/socket.io-client/blob/master/lib/socket.js#L511 ist ein Hauptgrund für diesen Fehler.

Jetzt vollständig reproduzieren:

1. Stellen Sie eine Verbindung zwischen Client und Server her.
2. Fügen Sie langsamen Code über Fakultät in Ihren Server ein (wir sollten den Hauptschleifen von node.js für 4-8 Sekunden anhalten):
   Funktion fibo (n) {
   wenn (n <2) 1 zurückgibt;
   Rückgabe von Fibo (n-2) + Fibo (n-1);
   }}
   Setzen Sie es in auth-Abschnitt. Dies sollte per Handschlag aufgerufen werden:
   io.set ('Autorisierung', Funktion (Daten, akzeptieren) {
   console.info ("Fibo ::" + fibo (41));
   Sie sollten in Ihrer Knotenkonsole experimentieren, um Fibo (N) zu finden, das
   blockiert die Hauptschleife für 4-8 Sekunden.
3. Jetzt sollten Sie Ihren Server schnell neu starten.
   Für die Verbindung gilt ein langsamer Code.
   Der Kunde sollte benachrichtigt werden, dass er nicht von Hand geschüttelt wird.
   Und jetzt versucht es, die Verbindung wiederherzustellen.
   In der Konsole werden mehrere Attemps zum erneuten Verbinden angezeigt (wenn Sie die Protokollierung für Rückrufe zum erneuten Verbinden / erneuten Verbinden aktivieren).
   Nach unserem Slowdown-Hack wird es für immer wiederholt.

Im wirklichen Leben wird dies durch Verlangsamung der Serverantwort mindestens für einige Sekunden reproduziert.
Dies kann der Fall sein, wenn node.js stark ausgelastet ist und mit einer gewissen Verzögerung reagiert.
Oder eine gewisse Netzwerkverlangsamung kann ebenfalls zu einem solchen Verhalten führen.
Es kann auch nach dem Neustart des Servers reproduziert werden.

Diese Zeile (socket.js, 511):
self.reconnectionTimer = setTimeout (vielleichtReconnect, self.reconnectionDelay);

Plant das Ereignis nach dem Verbindungsanruf. Wenn sich die Verbindungsantwort um mindestens eine Sekunde verzögert, wird sie ausgelöst und eine neue Wiederverbindung in die Warteschlange gestellt. Nach 2 Sekunden wird eine weitere hinzugefügt und so eine.

Ich habe ein Update durchgeführt, aber es ist nicht getestet und sieht nicht sehr solide aus. Hauptproblem - wie man überlegt, welcher Rückruf / Timer gleichzeitig mit der Funktion "Vielleicht wieder verbinden" ausgeführt werden kann.
Diese Zeile: https://github.com/LearnBoost/socket.io-client/blob/master/lib/socket.js#L490 kann auch zu einer doppelten Verbindung führen.

Der Socket.io-Client kann viel einfacher zu überlegen sein, wenn er für die Verwendung einer Zustandsmaschine überarbeitet wird. Derzeit ist der Status auf verschiedene Flags verteilt (verbunden, verbunden, wieder verbunden usw.). Und in vielen Funktionen sah ich Wachen wie "if (! Self.reconnecting)" und viele andere.
Die Zustandsmaschine kann diese Logik vereinfachen, um eine Reihe von Zuständen und Ereignissen zu haben. Und Timer können nur zum Auslösen von Ereignissen verwendet werden. Wenn dieses Ereignis den falschen Status erreicht hat, kann die Zustandsmaschine dieses Ereignis einfach ignorieren und sich nicht selbst stören.

Ich habe kein gutes STM für JS gefunden, aber dieses von Ruby kann einfach auf JS portiert werden: https://github.com/geekq/workflow

Auf jeden Fall +1 bei der Reparatur dieses Problems. Ich habe versucht, eine Lösung für dieses Problem zu finden, ohne socket.io oder socket.io-client direkt zu ändern, aber leider ist die einzige Methode, die ich zuverlässig gefunden habe, nur das Deaktivieren der erneuten Verbindung. Was definitiv keine gute Lösung ist, insbesondere angesichts der zunehmenden Nutzung mobiler Geräte, ist das Wiederverbinden eine große Anforderung.

Hat jemand eine Idee, wie dies auf die Prioritätenliste der Entwickler fällt?

Ah. Es sieht so aus, als ob dieses Problem 3rd-Eden aus dem folgenden Problem zugewiesen wurde: https://github.com/LearnBoost/socket.io/issues/430

Ich habe einen Fix für einen Client durchgeführt und eine Pull-Anfrage gesendet. Es funktioniert gut in 0.8.4 und kann in anderen Versionen gut funktionieren. Es ist jedoch erforderlich, in Quellen die Fähigkeit zu deaktivieren, AJAX (oder CORS) für den Handshake zu verwenden. Weitere Informationen finden Sie unter: https://github.com/LearnBoost/socket.io-client/pull/342 .

Entschuldigen Sie, dass Sie ein so altes Problem wiederbelebt haben. Ich verwende meiner Meinung nach die neueste Version von socket.io (oder zumindest habe ich npm socket.io installiert). Dieses Problem tritt immer noch bei mir auf. Ich bin relativ neu in socket.io und node.js als Ganzes. Ich hatte auch Probleme, bei denen manchmal die erste Verbindung (von den beiden, die ich bisher nur hatte) einen Lesefehler aufweist. Wenn ich richtig Cris sage, wurde Ihr Fix festgeschrieben, sodass es nicht mehr passieren sollte, aber es funktioniert immer noch, es sei denn, ich habe einen wichtigen Faktor übersehen?

Bearbeiten -

Es scheint knusprig gegabelt socket.io und hat eine Korrektur vorgenommen und die Korrektur wurde nicht auf die ursprüngliche socket.io festgeschrieben?

@JTallis Ich hatte das gleiche Problem wie @gdiz und sein Vorschlag funktionierte gut. Wenn Ihr Problem ähnlich ist, empfehlen wir Ihnen, es zu versuchen und uns mitzuteilen, wie es funktioniert.

Ich habe auch dieses Problem mit 0.9.16, von dem ich glaube, dass es die aktuellste Version ist. Wie kann gdiz dies verhindern? Ich habe es nicht ganz verstanden.

omg ... ich verbringe mehrere Stunden damit, herauszufinden, was mit meiner App nicht stimmt und warum Nachrichten zwischen Server- und Client-Masse nach Verbindungsverlust dupliziert und erneuert werden ...

Mit 0.9.16 kann ich dieses Problem bestätigen

Ich kann nach Belieben ein Doppelverbindungsereignis mit dem folgenden Client- und Servercode in derselben Datei node.js erhalten:

"use strict";
var server = require('socket.io');
var client = require('socket.io-client');

setTimeout(function () {
    var io = server.listen(8888);

    io.of('/chat').on('connection', function (socket) {
        console.log('Server: /chat connection');
    });

    io.sockets.on('connection', function (socket) {
        console.log('Server: connection');
    });
}, 2000);

var socketAddress = 'http://localhost:8888/chat';
var socket = client.connect(socketAddress);

socket.on('connect', function () {
    console.log("Client: connect");
});

socket.on('error', function () {
    console.log("Client: error");
    socket.socket.reconnect();
});

Ein paar seltsame Dinge:

1) Wenn ich die Namespace-Verbindung durch Entfernen des "/ chat" aus der URL in eine normale Verbindung ändere, gibt es nur ein Verbindungsereignis.

2) Wenn ich den Server sofort starte, ändern Sie die setInterval-Zeit auf Null. Es gibt keinen anfänglichen Verbindungsfehler und nur ein Verbindungsereignis.

Irgendwelche Workarounds oder Korrekturen dafür?

Das gleiche Problem haben. Wenn der socket.io-Server unerwartet neu gestartet wird, stellt der Client die Verbindung zweimal wieder her, sodass jede Nachricht vom Client zweimal verarbeitet wird. Versaut meine Zählungen auf der Client-Seite wirklich durcheinander.

Ich habe das gleiche Problem mit der Version 1.0.0-pre2. Ich habe zwei "400 Bad Request", wenn ich socket.io neu starte.

Werde das heute untersuchen!

Werde das heute untersuchen!

Zögern Sie nicht, wenn Sie weitere Details, Protokolle oder Bildschirme benötigen! Es ist nicht jedes Mal.

im Client socket.io.js in 1.0.6 in Zeile 2755:

Request.prototype.create = function (isBinary, supportBinary) {
var xhr = this.xhr = new XMLHttpRequest ({agent: this.agent, xdomain: this.xd});
...
}}

Ich halte es für eine gute Idee, Folgendes festzulegen:
xhr.timeout = Instanz von Manager._timeout - 10 ms
Auf diese Weise verhindern Sie die Erstellung mehrerer Client-Sockets auf der Client-Seite.
Auf der Serverseite treten bei mehreren Sockets Zeitüberschreitungen auf.

Das grundlegende Beispiel "Erste Schritte" für socket.io (http://socket.io/get-started/chat/) weist dieses Problem mit der doppelten Socket-Verbindung auf.

Eine der folgenden (in aufsteigender Reihenfolge der Wahrscheinlichkeit) ergibt die Double-Socket-Verbindung über eine einzelne Browser-Tab-Verbindung:
a) Beim Herstellen einer Verbindung zu localhost: 3000 über die erste Browser-Registerkarte
b) Beim Herstellen einer Verbindung zu localhost: 3000 über eine zweite Browser-Registerkarte
c) Lassen Sie die Browserkonsole geöffnet, bevor Sie eine Verbindung zu (localhost: 3000) herstellen.

Zusätzliche Beobachtungen:

 io.on('connection', function(socket){
    console.log('a user connected: ' + socket.id);
    socket.on('disconnect', function(){
       console.log('a user disconnected');
       console.log(socket.nickname + ' has disconnected from the chat.');
    });
});

1. Es gibt zwei unterschiedliche socket.id die von einer einzelnen Browser-Tab-Anfrage ausgehen.
2. Die "doppelte" Socket-Verbindung trennt sich in ungefähr einer Minute von selbst. Das console.log von "undefined hat die Verbindung zum Chat getrennt".
3. Wenn Sie den Expressgenerator 4.2 (mit Morgan) verwenden und dann das Beispiel "Erste Schritte" implementieren, führen die "guten" Browserverbindungen zu Expressprotokollen einer einzelnen Zeile, z. B. "GET / 304 1ms". Aber wann immer es diese "doppelte" Socket-Verbindung gibt, gibt es zwei Express-Protokolle, "GET / 304 1ms" UND "GET / 200 3ms - 386b".

Ich verwende Mac, Chrome, Express 4.2 und die neueste Version von socket.io.

Es gibt einen zeitlichen Unterschied zwischen der Erstellung der beiden Protokolle. Das erste Protokoll wird ausgelöst, wenn Chrome mein "lo" automatisch auf " localhost: 3000 "

Ich hatte eine Konsolenprotokollmeldung "X Benutzer verbunden" und war sehr ärgerlich, als mein eigener Browser 2 oder 3 Benutzerverbindungsbenachrichtigungen auslöste.

Jetzt muss ich gestehen, dass meine Lösung für das Problem darin bestand, die Zeile console.log zu kommentieren. Aber macht weiter so, Leute.

Ich sehe dieses Problem immer noch in der neuesten Version. Irgendwelche Updates dazu?

Ich sehe dieses Problem auch mit 1.0

Kann es überhaupt nicht reproduzieren. Kann jemand ein vollständiges Beispiel posten?

Am Freitag, den 14. November 2014 um 02:44:50 Uhr Rex Pechler [email protected]
schrieb:

Ich sehe dieses Problem auch mit 1.0

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/Automattic/socket.io/issues/474#issuecomment -62934229
.

Ich werde sehen, ob ich morgen ein einfaches Beispiel liefern kann.

Ich könnte es reproduzieren. Ich benutze socket.io 1.3.5 und drücke 4.12.4 aus.

Meine Express-App befindet sich auf 127.0.0.1:3000 und ich öffne meinen Browser und gebe die IP-Adresse ein und socket.io öffnet nur einen Websocket.

Ich habe eine Domain wie abc.com und leite sie an 127.0.0.1 weiter. Ich öffne abc.com in meinem Browser und in der Datei index.html befindet sich die Zeile.

<script>
        var socket = io('http://localhost:3000/mysql');

        socket.on('processlist', function (data){
            console.log(data);
        });
</script>

Dies öffnet 2 Websockets.

Ich habe Nginx noch nicht mit Proxy ausprobiert. Ich werde es dich wissen lassen, sobald ich es versuche.

Immer noch auf dieses Problem gestoßen. Bei mir ist es beim Neustart des Servers passiert - ich habe meine Ereignishandler socket.on ('message') angehängt, als das erste Verbindungsereignis vom Server ausgelöst wurde, und wenn der Server neu gestartet wurde, während der Client geöffnet war, wurde dieses Ereignis mehrmals ausgelöst (öfter die Der Client hat länger auf den Neustart des Servers gewartet.

Mein Fix für den Moment war es, das Socket-Ereignis, das angehängt wird, zu "entprellen", so dass es nur bei der ersten Serververbindung geschieht, wie folgt:

client.socketEventsAttached = false;

socket.on('connect',function(){
     if (!client.socketEventsAttached){
          attachSocketEvents();
     }
});

Sie können Ihre Listener für Nachrichtenereignisse auch außerhalb des Listeners socket.on ('connect') platzieren, wie von @gdiz vorgeschlagen. Ich hatte dort gerade einige Probleme mit Socket-Ereignissen, bevor der Server oder Client für sie bereit ist.

@bbcollinsworth Was ist das Client-Objekt?

Dieses Problem tritt immer noch mit einem neuen Socketio und einem einfachen Beispiel auf.

Ich stoße immer noch auf dieses Problem, wie im folgenden Beispiel beschrieben.

EDIT: Ich habe eine Lösung gefunden, obwohl ich nicht sicher bin, ob sie genau richtig ist. Im Wesentlichen ist nur die Verwendung erforderlich

io.once('connection', ...)

Anstatt von

io.on('connection', ...)

@brandonraphael Könnten Sie bitte ein Beispiel für die Reproduktion Ihres Problems (basierend auf https://github.com/darrachequesne/socket.io-fiddle zum Beispiel) bereitstellen und ein neues Problem eröffnen?

Jedes Update, das dies noch tut, führt zu Problemen in der App

Dies sind die Protokolle -
0 | Api Server | In Verbindung gebracht!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! DKap3hUYFSpKBRr7AFgc 4351 2018-12-26 10:58:25
0 | Api Server | In Verbindung gebracht!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! VS98DBFVTNF6ifzmAFgd 4351 2018-12-26 10:58:25

4351 ist die Benutzer-ID und die Anzahl der Verbindungen ist auch nicht statisch wie 2 im Fall von Benutzer 4351.
Ein anderes Protokoll zeigt 6 Verbindungen gleichzeitig für denselben Benutzer.

Außerdem haben Sie diese beiden Socket-IDs auf dem Server überprüft und sie werden als gültig angezeigt. Das Frontend kann jedoch nur einen von ihnen anhören, bei dem es sich immer um die erste Socket-ID handelt.

Jede Hilfe wäre wirklich toll.
Danke im Voraus.

Ich stoße immer noch auf dieses Problem, wie im folgenden Beispiel beschrieben.

EDIT: Ich habe eine Lösung gefunden, obwohl ich nicht sicher bin, ob sie genau richtig ist. Im Wesentlichen ist nur die Verwendung erforderlich

io.once('connection', ...)

Anstatt von

io.on('connection', ...)

Danke dafür

Das Problem wurde behoben, nachdem die auf dem Client verwendete Version geändert wurde. Eine andere Lösung wäre, Räume anstelle einer einzelnen Socket-ID zu verwenden. Es wurde herausgefunden, dass jede Socket-ID selbst ein Raum ist. Nur ein Teil, der geändert werden sollte, war der neue Verbindungscode zum Platzieren jeder Socket-ID im Benutzerraum.
Angenommen, ein Benutzer-Slug ist Benutzer1, dann wurde ein Raum Benutzer1 erstellt und jede neue Socket-Verbindung über den Slug Benutzer1 wurde in den Raum Benutzer1 gestellt.

Hatte das gleiche Problem und es machte mich verrückt. Registrierte Event-Listener definitiv NICHT erneut auf dem Client. In meinem Setup habe ich einen NodeJS-Server, auf dem der Socketio-Endpunkt gehostet wird, und einen anderen NodeJS-Server, der als Socketio-Client fungiert. Der Trick bestand darin, die Clientseite mit dem Websocket-Transport zu verbinden und forceNode . Ex

// client side
const socket = io('<url>', {
  transports: ['websocket'],
  forceNode: true,
});

Ich glaube, ich habe das gleiche Problem. Ich baue einen Chatraum und wenn jemand den Raum betritt, sende ich ein "hat sich dem Raum angeschlossen "Nachricht an den Raum.

Alles funktioniert gut, aber wenn ich den Raum verlasse und ihn dann ein zweites Mal betrete, wird die Intro-Nachricht zweimal ausgegeben. Wenn ich den Raum wieder verlasse und ihn ein drittes Mal wieder betrete, wird die Intro-Nachricht dreimal ausgegeben und so weiter. Jede Wiederverbindung zum gleichen Raum führt zu einer doppelten Intro-Nachricht. Wenn ich jedoch einen anderen Raum betrete, wird die Intro-Nachricht nur einmal angezeigt.

Die Verwendung von io.once('connection', ...) hat bei mir nicht funktioniert. Tatsächlich funktionierten alle meine Veranstaltungen nicht mehr.

Die Verwendung der "Debounce" -Methode funktionierte ebenfalls nicht. Auch hier hat sich keine meiner Veranstaltungen registriert.

Schließlich hat die Verwendung der Client-Seite forceNode: true Option

Ich verwende 2.2.0 sowohl auf dem Server als auch auf dem Client. Fehlt mir etwas?

Ich habe mich über das gleiche Problem gewundert, aber letztendlich hat es geholfen, dem Client zu sagen, dass er nur once .

Hier ist meine Konfiguration für den Client:

var socket = io.connect("http://localhost:3000/test", 
    { upgrade: false, transports: ['websocket'], reconnection: true, forceNew: false});
socket.once('connect', socketConn => {
    socket.on('message', data => {
        console.log(data);
    });
}); 

Der Kunde wird nur once für connect registriert, sodass jedes andere darin enthaltene Ereignis einmal registriert wird. Wenn der Server nun abstürzt, versucht der Client nur, erneut eine Verbindung herzustellen, und versucht nicht, eine neue Verbindung herzustellen. Sobald die Antwort vom Server eingeht, werden die Nachrichten verarbeitet.

io.once muss also auf der Clientseite und nicht auf der Serverseite festgelegt werden.

Ich verwende Client 2.1 Version. Ich finde es sehr einfach, es in meiner Entwicklungsumgebung auszulösen. Jedes Mal, wenn mein Knotenserver neu gestartet wird (z. B. mit nodemon), löst der Client immer mehrere Wiederverbindungsereignisse aus und stellt dann sogar eine Verbindung her. Aber ich kann die Grundursache nicht herausfinden

Ich verwende Client 2.1 Version. Ich finde es sehr einfach, es in meiner Entwicklungsumgebung auszulösen. Jedes Mal, wenn mein Knotenserver neu gestartet wird (z. B. mit nodemon), löst der Client immer mehrere Wiederverbindungsereignisse aus und stellt dann sogar eine Verbindung her. Aber ich kann die Grundursache nicht herausfinden

Ich hatte das gleiche Problem wie bei der Verwendung von nodemon selbst. Letztendlich half es jedoch, dem Client zu sagen, er solle nur once .
Versuchen Sie den Code aus meiner Antwort oben. Es hat mir geholfen und jedes Mal, wenn der Server neu gestartet wird, erhalten Clients neue Verbindungen.

Mein Problem war einfach

Ich hatte die gleiche clientseitige App auf 2 Registerkarten geöffnet. Hoppla

Ich hatte auch das gleiche Problem. Für mich habe ich jedoch fälschlicherweise meine clientseitigen Handler in die Rückruffunktion socket.on('connection', cb) eingefügt.

Hier ist ein Ausschnitt, um zu demonstrieren:

client.js (in node.js)

const client = require('socket.io-client');
const socket = client('my_endpoint', {
  transports: [ 'websockets' ]
});

socket.on('connect', () => {
  console.log('connected');
  socket.on('myEvent', (message) => {
    console.log(`message: ${message}`);
  });
});

Wenn eine Verbindung getrennt und erneut hergestellt wurde, wurde erneut socket.on('connect', cb) aufgerufen, und der Handler myEvent registrierte einen zweiten Handler mit demselben Namen. Wenn der Server also wieder myEvent ausgibt, habe ich zwei Konsolenprotokolle derselben Nachricht.

Um dies zu beheben, musste ich meine anderen Handler außerhalb des connect Handlers platzieren.

const client = require('socket.io-client');
const socket = client('my_endpoint', {
  transports: [ 'websockets' ]
});

socket.on('connect', () => {
  console.log('connected');
});

socket.on('myEvent', (message) => {
  console.log(`message: ${message}`);
});

Ich glaube, meine Verwirrung kam davon, wie die Dokumente zeigen, dass die serverseitige socket.on Ereignisse in das connect Ereignis einfügt. Das liegt an mir, weil ich die Dokumente nicht genauer gelesen habe, aber ich dachte, ich würde das hier einfügen, falls jemand anderes den gleichen Fehler macht.

Auch wenn ich dieses Problem speziell in node.js gesehen habe, bin ich mir sicher, dass dies auch im Browser ein Problem sein würde.