Socket.io: Doppelte Verbindung

Erstellt am 23. Aug. 2011  Â·  42Kommentare  Â·  Quelle: socketio/socket.io

Irgendwie passiert eine doppelte Verbindung mit Clients (was bedeutet, dass alle Handler zweimal aufgerufen werden), konnte die Situation nicht selbst reproduzieren, aber weiterhin Fehlerberichte erhalten. Das Verhalten ist genau das gleiche, wenn Sie socket.socket.connect () auf bereits verbunden aufrufen Socket (getestet auf Websocket und Flashsocket)

Socket.IO client bug

Hilfreichster Kommentar

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', ...)

Alle 42 Kommentare

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.

screen shot 2015-05-29 at 23 53 29

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.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

MickL picture MickL  Â·  12Kommentare

edmellum picture edmellum  Â·  130Kommentare

windwalker picture windwalker  Â·  7Kommentare

saifulshihab picture saifulshihab  Â·  7Kommentare

betooo0997 picture betooo0997  Â·  5Kommentare