Socket.io: Fahrplan für v3

Sieht nach einem tollen Plan aus.

Ich wechsle von nodejs zu golang und habe festgestellt, dass es keine socket.io 2-Implementierung gibt.
https://github.com/googollee/go-socket.io/issues/188

Was halten Sie von der Golang-Server-Unterstützung für v3? Gerne beteilige ich mich an dieser Entwicklung.

@theromis sprechen Sie von einem Golang-Client (der eine Verbindung zum Node.js-Server herstellt) oder einem tatsächlichen Golang-Server? (Ich denke, hier wurde auch etwas gearbeitet: https://github.com/graarh/golang-socketio)

@darrachequesne Vielen Dank für die schnelle Antwort, ja, ich spreche von serverseitigem Golang-Socketio.
Das von Ihnen erwähnte Projekt ist fast tot (letztes Commit vor mehr als einem Jahr).
https://github.com/googollee/go-socket.io Projekt sucht Betreuer.
Und keiner von ihnen unterstützt socket.io v2.
Ich dachte, die größten Nodejs-Socketio-Entwickler könnten auch an der Golang-Entwicklung interessiert sein :)

Aktualisierter Java-Client wäre auch schön.

Ein socket.io-Paket für serverseitigen Swift wie https://github.com/vapor wäre auch sehr nett, da es bereits einen Swift-Client gibt.

Klingt so, als ob serverseitig socket.io in einer nativen Sprache wie C/C++ geschrieben wird, es überall verwendet werden kann, einschließlich nodejs, golang, java, rust und was auch immer ...
Was ist falsch an diesem Ansatz?
Meine persönliche Meinung socket.io ist wie de facto Standard für die moderne Welt. Warum nicht ideal machen?

Eine Sache, die mich immer an socket.io gestört hat und die in der nächsten Hauptversion behoben werden könnte, könnte https://github.com/socketio/socket.io/issues/2124 und https://github.com sein

Es gab eine historische Inkonsistenz bei der Handhabung von Namespaces und Middlewares.
Außerdem macht das client , das ein reconnect -Ereignis ausgibt, meiner Meinung nach mehr Sinn, nachdem es sich mit namespace verbindet, anstatt nur das Wiederverbindungsereignis des Managers zu sein ... Zum Beispiel , wenn ein Authentifizierungsfehler in einer Sub-Namespace-Middleware auftritt, erhält der Client immer noch ein Wiederverbindungsereignis, was meiner Meinung nach kontraintuitiv ist.

Ab der Node-Version 10.5 gibt es einen neuen Worker-Thread, der sich derzeit im experimentellen Zustand befindet, aber wenn er veröffentlicht wird, kann er meiner Meinung nach eine bessere Möglichkeit für die Verwendung von socket.io sein, anstatt den Redis-Server zu verwenden.

Profi:

• weniger Abhängigkeit (redis)
• native Unterstützung von Multi-Threading
• mehr Kontrolle

Nachteil:

• funktioniert nur ab dieser nodejs-Version, die den Worker-Thread (10.x || 11) freigibt. Aber das lässt sich umgehen.

@Zwei ist interessant! Es würde für Worker auf demselben Host funktionieren, aber was ist mit mehreren Hosts?

@perrin4869 gute Idee :+1:

Ich habe hier viele Ideen hinterlassen: #3311 bitte lesen :) Werde das hier schließen und die Diskussion fortsetzen.

@MickL hätten Sie etwas Zeit, um das socket.io- Repository beispielsweise auf Typescript zu migrieren?

Ich fürchte, mein Wissen über Netzwerktechnologie und Informationssicherheit ist begrenzt. Ich verlasse mich auf High-Level-Frameworks wie Express oder Socket.io.

Soweit ich sehe, ist socket.io bereits OOP geschrieben und gut dokumentiert, so dass es ein Kinderspiel wäre, es einfach zu portieren. Meine Idee war es, so modular wie möglich vorzugehen, damit jemand wie ich einfacher etwas beitragen kann und der Kunde baumerschütterbar ist. Es könnte auch eine Idee sein, reaktiver zu werden, um die Dinge einfacher zu machen. Wie auch immer, ich bin nicht genug in den Code, also könnten beide Ideen in diesem Projekt möglicherweise keinen Sinn machen.

@darrachequesne ist eine gute Frage. Ich werde darüber nachdenken.

Benötigen Sie Nodejs 8 und höher, da frühere Versionen bestenfalls gewartet werden, siehe https://nodejs.org/en/about/releases/ , zumindest sollte nodejs 4 fallen gelassen werden (ich habe aus .travis.yml bemerkt, dass Sie es unterstützen es)

Wurde in einem Branch/Repo mit 3.0-bezogenen Arbeiten begonnen? Ich schaue nur, ob es einen Ort gibt, an dem man darüber informiert bleiben kann, wie es läuft oder einen Beitrag leistet.

Ich würde mir eine verbesserte Unterstützung für die Fehlerbehandlung auf der Serverseite wünschen. Dies wurde in einigen anderen Ausgaben angesprochen, aber genauer gesagt wäre es großartig, wenn:

1. Zusätzlich zum Standard wurde eine benutzerdefinierte Fehlerbehandlungs-Middleware unterstützt. Dies könnte in etwa so aussehen wie bei Express (das als letztes in der Kette von app.use() angehängt werden kann, ähnlich wie socket.use() , Middlewares): https://expressjs.com/en/guide/error -handhabung.html

Das Problem besteht derzeit darin, dass es keine Möglichkeit gibt, einem Fehler irgendeine Art von Nachverfolgung oder Protokollierung hinzuzufügen, sobald er nexted war.

1. Da der 'error'-Namespace auf der schwarzen Liste steht, socket.emit('error', err) wird der Client nicht hören), kann ich nicht emit einen Fehler irgendwo auf dem Server feststellen, der nicht einfach ist Zugriff auf next() (dh innerhalb von socket.on('event') ). Dies macht es schwierig, eine einheitliche Fehlerbehandlungslösung zu erstellen.

2. next(err) sollte statt eines Strings ein Error -Objekt senden. Ich verstehe, dass es dafür eine Problemumgehung gibt (https://github.com/socketio/socket.io/issues/3371), indem eine magische .data -Eigenschaft zu jedem Objekt hinzugefügt wird, das Sie next() nennen an. Dies ist jedoch nicht dokumentiert und nicht intuitiv.

Im Allgemeinen erscheint next(err) wie eine unnötige Blackbox mit sehr begrenzter Fehlerbehandlungskapazität.

Danke für deine Mühe und bleib dran!

@darrachequesne Gibt es ein Update zu v3, das Realität ist? Seit 2018 sehe ich diesbezüglich keine Fortschritte.

Ein kurzes Update: Mein aktueller Vertrag wurde kürzlich aktualisiert, und ich sollte in der Lage sein, einen Tag pro Woche (1/5) der Projektpflege zu widmen. Daher sollte die Arbeit an v3 in Kürze wieder aufgenommen werden.

Wirklich daran interessiert, bei diesem Projekt auf die eine oder andere Weise zu helfen.

Wenn es eine Möglichkeit gibt, herauszufinden, wie ich dies tun kann, lassen Sie es mich wissen - ich möchte nur möglicherweise keine Dinge reparieren, damit sie nicht zusammengeführt werden! Also lieber auf eine Anleitung warten, falls Hilfe benötigt wird. Prost

• Komprimierung (gzip, zlib, defalte/inflate)
• Überarbeitungsmechanismus zum Senden von Binärdaten (jetzt 2 Pakete ... ws Text und ws Binary)
• Metadaten bei Verbindung senden (Komprimierung verwenden?)
• Coder/Encoder als Plugins enthalten benutzerdefinierte (messagepack, protobuf usw.), wir könnten Generika verwenden, wenn der Code in Typoskript umgeschrieben wird
• Zertifikat-Pinning (server-/clientseitig)

@blackkopcap

Komprimierung (gzip, zlib, defalte/inflate)

Komprimierung wird bereits unterstützt (https://github.com/socketio/engine.io/blob/a05379b1e87d2e4cde40d3e30b134355883f4108/lib/transports/polling.js#L249-L298). Die WebSocket-Komprimierung ( perMessageDeflate ) wird in v3 jedoch standardmäßig deaktiviert, da sie viel zusätzlichen Speicher benötigt.

Überarbeitungsmechanismus zum Senden von Binärdaten (jetzt 2 Pakete ... ws Text und ws Binary)

Völlig einverstanden. Karte hier hinzugefügt

Metadaten bei Verbindung senden (Komprimierung verwenden?)

Ich bin mir nicht sicher ob ich das verstehe. Könnten Sie bitte den Anwendungsfall erläutern?

Coder/Encoder als Plugins enthalten benutzerdefinierte (messagepack, protobuf usw.), wir könnten Generika verwenden, wenn der Code in Typoskript umgeschrieben wird

Sie sollten bereits in der Lage sein, Ihren eigenen Parser wie socket.io-msgpack-parser bereitzustellen

Zertifikat-Pinning (server-/clientseitig)

:+1:, hier hinzugefügt.

@michaelegregious

1. Zusätzlich zum Standard wurde eine benutzerdefinierte Fehlerbehandlungs-Middleware unterstützt. Dies könnte in etwa so aussehen wie bei Express (das als letztes in der Kette von app.use() angehängt werden kann, ähnlich wie socket.use() , Middlewares): https://expressjs.com/en/guide/error -handhabung.html

Das wäre in der Tat großartig. Hier hinzugefügt

1. Da der 'error'-Namespace auf der schwarzen Liste steht ( socket.emit('error', err) wird vom Client nicht gehört), kann ich nicht emit einen Fehler irgendwo auf dem Server erkennen, der nicht einfach ist Zugriff auf next() (dh innerhalb von socket.on('event') ). Dies macht es schwierig, eine einheitliche Fehlerbehandlungslösung zu erstellen.

Nicht sicher, was wir tun könnten. Haben Sie einen Vorschlag?

1. next(err) sollte statt eines Strings ein Error -Objekt versenden. Ich verstehe, dass es dafür eine Problemumgehung gibt (https://github.com/socketio/socket.io/issues/3371), indem eine magische .data -Eigenschaft zu jedem Objekt hinzugefügt wird, das Sie next() nennen an. Dies ist jedoch nicht dokumentiert und nicht intuitiv.

Stimme voll und ganz zu :+1: , hier hinzugefügt

Wir haben bereits Engine.IO v4 veröffentlicht, das in Socket.IO v3 enthalten sein wird. Die Versionshinweise finden Sie hier .

Ich habe das, was ich in diesem Thread finden konnte, dem Projekt hier hinzugefügt, um einen Überblick über den Fortschritt zu geben. Zögern Sie nicht zu kommentieren!

Folgendes hatte ich im Sinn, um https://github.com/socketio/socket.io/issues/2124 zu reparieren

Der Client sendet nun ein CONNECT -Paket, wenn er Zugriff auf den Standard-Namespace ( / ) erhalten möchte (keine implizite Verbindung mehr).

Dies würde bedeuten, dass die für den Standard-Namespace registrierten Middlewares nicht mehr für Clients gelten, die Zugriff auf einen nicht standardmäßigen Namespace erhalten möchten

// server-side
io.use((socket, next) => {
  // not triggered anymore
});

io.of('/admin').use((socket, next => {
  // triggered
});

// client-side
const socket = io('/admin');

Auf der Client-Seite sollten wir meines Erachtens auch klar zwischen der Option query für den Manager (die in den Abfrageparametern enthalten ist) und der Option query für den Socket (die wird im Paket CONNECT gesendet).

Im Augenblick:

const socket = io('/admin', {
  query: {
    abc: 'def'
  }
});

führt zu Anfragen wie GET /socket.io/?transport=polling&abc=def und auch zu einem CONNECT-Paket wie { "type": 0, "nsp": "admin?abc=def"}

Da es außerdem kein CONNECT -Paket für den Standard-Namespace gibt, wird das query des Sockets in diesem Fall derzeit ignoriert.

Ich schlage vor, es stattdessen in authQuery umzubenennen.

const socket = io({
  query: {
    abc: 'def'
  },
  authQuery: {
    abc: '123'
  }
});

würde zu Anfragen wie GET /socket.io/?transport=polling&abc=def und einem CONNECT-Paket wie { "type": 0, "nsp": "/", "data": { abc: '123' } } führen

@perrin4869 würde es Sinn machen?

Bearbeiten: In Bezug auf Kompromisse gibt es beim Start mehr HTTP-Anforderungen ...

Server > Client: Engine.IO handshake
Client > Server: Socket.IO connect
Server > Client: Socket.IO connect

Während wir derzeit haben:

// without middleware on the default namespace (only 1 GET request)
Server > Client: Engine.IO handshake + Socket.IO connect
// with at least a middleware (2 GET requests)
Server > Client: Engine.IO handshake
Server > Client: Socket.IO connect

@darrachequesne Vielen Dank, dass Sie dies berücksichtigen! Es ist schön, hier einen Abschluss zu bekommen, endlich in der Lage, den Code zu vereinfachen, den ich damals hatte: D
Es ist lange her, also erinnere ich mich nicht genau, aber das klingt nach der Lösung, die ich anstrebte
Aus Neugier, was ist der Grund für die Kompromisse?

Nach der Idee, wie js-Formen funktionieren: https://web.archive.org/web/20200201163000/https ://mathiasbynens.be/notes/shapes-ics. Wäre es nicht besser, Arrays zum Speichern von Referenzen für Socket-Verbindungen zu verwenden, um die Leistung zu verbessern? Immer mehr Verbindungen, unzählige IDs und die Verwendung von Objekten, um dies zu tun, mit jeder neuen Verbindung wird eine neue Form generiert und mehr Speicher verbraucht, abhängig von der Lebensdauer eines Knotens und der Anzahl der Verbindungen, die er haben kann, wird dies wahrscheinlich sein einige negative Auswirkungen auf die Leistung.

@perrin4869 Die Kompromisse ergeben sich aus der aktuellen Implementierung, da wir zuerst die Engine.IO-Verbindung herstellen und dann mit der Socket.IO-Verbindung fortfahren. Was ergibt, wenn der HTTP-Long-Polling-Transport aktiviert ist (was die Standardeinstellung ist):

• eine HTTP GET-Anforderung zum Abrufen des Engine.IO-Handshakes
• eine HTTP-POST-Anforderung zum Senden des Socket.IO CONNECT -Pakets
• eine HTTP GET-Anfrage, um das Socket.IO CONNECT -Paket vom Server abzurufen
• und dann das Upgrade auf WebSocket

Aber es ist sicherlich verbesserungswürdig. Als Referenz wurde die Änderung hier und hier implementiert.

Außerdem wird das Ereignis reconnect nicht mehr von der Socket-Instanz (clientseitig) ausgegeben ( hier ).

@ferco0 verwenden wir jetzt ein Map anstelle eines einfachen Objekts (https://github.com/socketio/socket.io/commit/84437dc2a682add44bb57d03f703cfc955607352). Gilt Ihr Kommentar in diesem Fall immer noch?

[email protected] und [email protected] wurden veröffentlicht :fire:

Ein paar Anmerkungen:

• die öffentliche API ändert sich nicht viel (ein paar Methoden wurden jedoch entfernt, siehe hier und hier als Referenz)
• Die Codebasis wurde auf TypeScript migriert, aber einige Eingaben fehlen, insbesondere auf der Client-Seite.
• die Breaking Changes in Engine.IO v4 ( hier aufgeführt) wurden aufgenommen
• Die Client-Bundle-Größe hat sich etwas erhöht, obwohl es weniger Abhängigkeiten gibt, ich werde darauf eingehen

Jedes Feedback ist willkommen!

@darrachequesne das ist ok.

@darrachequesne Viele npm-Open-Source-Projekte versuchen, die Anzahl der Abhängigkeiten zu verringern. Es ist ein gewisser Trend innerhalb der Community. Der Hauptgrund dafür ist, dass viele Organisationen verlangen, dass Lizenzen aller verwendeten Abhängigkeiten überprüft werden, wenn sie in Projekten verwendet werden, um keine rechtlichen Probleme zu bekommen. Weniger Abhängigkeiten zu haben hilft dabei natürlich. Als Beispiel wurde Helm (ein großartiges Sicherheitspaket für den Express-Webserver) in der neuesten Version 4.0 auf eine Null-Abhängigkeits-Installation umgestellt.

Gibt es vor diesem Hintergrund einen Plan, die Anzahl der Abhängigkeiten in socket.io in Release 3 zu verringern?

@thernstig das ist eine gute Frage! Wir haben tatsächlich versucht, die Anzahl der Abhängigkeiten in Socket.IO v3 zu reduzieren:

npm i [email protected] => 48 packages
npm i [email protected] => 33 packages

npm i [email protected] => 37 packages
npm i [email protected] => 20 packages

Hier ist der Abhängigkeitsbaum für den Server:

[email protected]
├── [email protected]
├─┬ [email protected]
│ └── [email protected]
├─┬ [email protected]
│ ├─┬ [email protected]
│ │ ├─┬ [email protected]
│ │ │ └── [email protected]
│ │ └── [email protected]
│ ├── [email protected] deduped
│ ├── [email protected]
│ ├─┬ [email protected]
│ │ ├── [email protected]
│ │ └── [email protected]
│ ├── [email protected] deduped
│ ├── [email protected]
│ └── [email protected]
├── [email protected]
├─┬ [email protected]
│ ├── @types/[email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected]
│ ├── [email protected] deduped
│ ├─┬ [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected] deduped
│ │ ├── [email protected] deduped
│ │ ├── [email protected] deduped
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ ├─┬ [email protected]
│ │ │ └─┬ [email protected]
│ │ │   └── [email protected]
│ │ ├── [email protected]
│ │ ├── [email protected]
│ │ └── [email protected]
│ ├── [email protected]
│ └── [email protected] deduped
└─┬ [email protected]
  ├── [email protected] deduped
  └── [email protected] deduped

Ich denke, dass wir nur den dist/ -Ordner des socket.io-client -Pakets benötigen, daher könnte es sinnvoll sein, ein socket.io-client-dist $-Paket ohne Abhängigkeiten zu erstellen. Was denken Sie?

Hinweis: Steckdose. [email protected] und Sockel. [email protected] wurden veröffentlicht

Ich habe einige Beispiele mit ES-Modulen und TypeScript hinzugefügt.

@darrachequesne Das überlasse ich ganz deinem Ermessen 😄

@michaelegregious in Bezug auf Ihren Kommentar , ich weiß, es ist eine ganze Weile her, aber hatten Sie eine bestimmte API im Sinn?

Ich stimme zu, dass die aktuelle API verbessert werden könnte. Es wurde implementiert, um einen Catch-All-Listener zu haben (wird hier besprochen), und nicht mit Blick auf die Fehlerbehandlung.

Wir könnten auch eine Möglichkeit hinzufügen, Benutzer vor unbehandelten Ereignissen zu warnen (404-Antworten in Express, http://expressjs.com/en/starter/faq.html#how-do-i-handle-404-responses).

@darrachequesne schön zu hören, dass du an der nächsten Version von socket.io arbeitest !! Vielen Dank im Voraus für all Ihre Arbeit an dieser Bibliothek.

Socket teste ich gerade. [email protected] und Socket. [email protected] und ich versuche, die neue Syntax zu verwenden, um einem Raum beizutreten und an Steckdosen in diesem Raum zu senden.

Ich kann den Server nicht dazu bringen, mit Ihrem Beispiel in der Änderungsprotokolldatei an den Client-Socket zu senden.

socket.join("room1"); io.to("room1").emit("hello");

Im Anhang sind Screenshots, die die auf dem Client verwendete Socket-js-Datei und den Code für den node.js-Server zeigen

clientseitige js-Datei

clientseitiges socket.on-Ereignis

serverseitige Join-Syntax innerhalb von io.on("connect",

Ich habe alle Methoden im letzten Screenshot ausprobiert, um es an den Client zu senden, und nichts funktioniert.

Bitte lassen Sie mich wissen, wenn Sie weitere Informationen benötigen.

Danke

@darrachequesne Ich habe auf 3.0.0-rc2 heruntergestuft und trete dem Raum bei, indem ich join mit der Callback-Methode namens "room1" verwende, die ausgelöst wird, aber keines der Emit-Ereignisse an den Client gesendet wird

socket.join("room1", () => { console.log('old way to join'); io.to("room1").emit("hello", {}); io.in("room1").emit("hello", {}); });

Ich habe auch 3.0.0-rc2 deinstalliert und socket.io 2.3.0 für Server und Client installiert und bestätigt, dass der obige Code wie erwartet funktioniert. Ich glaube also, dass bei den 3.0.0 rc-Versionen etwas kaputt ist

@szarkowicz Hmm ... Ich kann das von Ihnen beschriebene Verhalten nicht reproduzieren: https://github.com/socketio/socket.io-fiddle/tree/issue/v3

Der folgende Code scheint wie erwartet zu funktionieren:

socket.join("room1");

io.to("room1").emit('hello', 1, '2', {
  hello: 'you'
});

Bekommst du einen Fehler in der Konsole? Erhalten Sie ein connect -Ereignis auf der Client-Seite?

@darrachequesne danke für die Bestätigung. Ich habe es auf die Verwendung des redisAdapter zurückgeführt, der das Problem verursacht. Sobald ich den folgenden Code auskommentiere, funktioniert die rc3-Version von socket.io wie erwartet.

let redisAdapter = require('socket.io-redis');
io.adapter(redisAdapter({ host: 'localhost', port: 6379 }));

Haben Sie versucht, redis mit der v3 von socket.io zu verwenden?

Danke

@szarkowicz ja, Sie haben absolut Recht, der Redis-Adapter muss aktualisiert werden, um mit Socket.IO v3 kompatibel zu sein, er wird direkt nach der Veröffentlichung von 3.0.0 aktualisiert (was bald sein sollte).

Auf jeden Fall vielen Dank für das Feedback :+1:

@darrachequesne okay hört sich gut an!!! Ich werde if vorerst einfach nicht verwenden und ohne es weiter testen.

Gibt es eine Zeit, zu der Sie glauben, dass v3 veröffentlicht wird?

Keine Sorge - nochmals vielen Dank, dass Sie sich bei mir gemeldet haben und an allen Verbesserungen für die nächste Version gearbeitet haben!!

@darrachequesne Vielen Dank für diese Updates! Sorry für meine verspätete Antwort! Wir verwenden socket.io nicht in meinem aktuellen Projekt (obwohl wir es möglicherweise in Zukunft integrieren werden), aber die Problemumgehung, die ich in meinem letzten Projekt verwendet habe, war die Verwendung socket.emit('err', err) anstelle des privilegierten Namespace socket.emit('error', err) .

Hier ist die Notiz, die ich in die Readme-Datei unserer App eingefügt habe, um das Problem zu erklären:

#### Error Handling Patterns
Most of the communication between client and server in the app happens via `socket.io`. For server-side error-handling, `socket.io` exposes [Express](https://expressjs.com/en/guide/error-handling.html)-like middleware via `socket.use(socket, next)`. Middlewares can be chained to separate concerns for authentication, logging, etc.

Unlike `Express`, however, `socket.io`'s native `next(err)` does not support addition of custom error handlers. Calling `next(err)` immediately breaks out of the middleware chain. Additionally, the privileged `error` namespace (emitted by `next(err)` and received by the client via `socket.on('error', err)`) is not available for use via the standard `socket.emit('error', err)` on the server. 

For these reasons, the server instead emits all errors to the client via `socket.emit('err', err)`. We use a `./CustomError` Class (inheriting from the native JS Error) to namespace our errors, and then rely on a switch to properly route errors on the client. (This also allows us to track and log outgoing errors via custom middleware on the server.)

Wenn Sie also noch einmal darüber nachdenken, wenn Sie bereits die Möglichkeit zum Hinzufügen einer benutzerdefinierten Middleware zu next(err) integriert haben, ist es auch möglich, die Verwendung des socket.emit('error', err) -Namespace für die manuelle Verwendung auf der Server?

Ich schaue auf diesen Code zurück und alle meine Event-Handler sehen so aus (wenn es hilfreich ist zu sehen):

    socket.on('quotes', async (params) => {
      try {
        await dispatchQuotes(socket, params);
      } catch (err) {
        socket.emit('err', err);
      }
    });

Oh! Noch eine Sache, an die ich mich erinnere. Hier ist eine Problemumgehung, die ich verwendet habe, um ausgehende Ereignisse zum Zweck der Protokollierung/Fehlerbehandlung überwachen zu können:

  ioServer.on('connection', (socket: Socket) => {
    const emitter = socket.emit;

    // We modify socket.io's native 'emit' method to monitor outgoing
    // events, since socket.use() (middleware) only tracks incoming events.
    socket.emit = (...args: any) => {
      emitter.apply(socket, args);
      outgoingErrorMiddleware(socket, args, app);
    };

etc.

So habe ich die ausgehende Middleware verwendet, wenn es hilfreich ist, sie zu sehen:

export function outgoingErrorMiddleware(socket: SocketIO$Socket, packet: Packet, app: App) {
  const [eventName, err] = packet;
  const { metrics } = app.locals;
  if (eventName === 'err') {
    logger.error(err);
    metrics.errors += 1;
  }
}

Nochmals vielen Dank für all Ihre harte Arbeit! Ich versuche das nächste mal schneller zu antworten.

1. Da der 'Fehler'-Namespace auf der schwarzen Liste steht ( socket.emit('error', err) wird vom Client nicht gehört), kann ich nicht emit einen Fehler irgendwo auf dem Server erkennen, der nicht einfach ist Zugriff auf next() (dh innerhalb von socket.on('event') ). Dies macht es schwierig, eine einheitliche Fehlerbehandlungslösung zu erstellen.

Nicht sicher, was wir tun könnten. Haben Sie einen Vorschlag?

@michaelegregious danke für die Beispiele, die Sie bereitgestellt haben. (und kein Problem für die Verzögerung!)

Technisch gesehen bin ich mir nicht sicher, ob wir die Fehler abfangen können, die von einem asynchronen Listener ausgelöst werden:

socket.on("test", async () => {
  throw new Error("catch me?");
});

try {
  socket.emit("test");
} catch (e) {
  // won't catch the error
}

Daher denke ich, dass es besser ist, den Benutzer die Fehler selbst behandeln zu lassen, entweder mit dem von Ihnen bereitgestellten Code ( socket.emit("err", err); ) oder mit einer Bestätigungsfunktion:

socket.on('quotes', async (params, cb) => {
  try {
    await dispatchQuotes(socket, params);
  } catch (err) {
    cb(err);
  }
});

Was denken Sie?

Was ist derzeit für v3 implementiert:

• "error" wird in "connect_error" umbenannt und ist nur auf Namespace-Middleware-Fehler beschränkt:

// server
io.use((socket, next) => {
  next(new Error("unauthorized"));
});
// client
socket.on("connect_error", (err) => {
  // err instanceof Error === true
  // err.message === "unauthorized"
})

Das bedeutet auch, dass „Fehler“ kein reservierter Ereignisname mehr ist.

• socket.use() wird entfernt und durch socket.onAny() ersetzt (Server und Client)

// server
io.on("connect", (socket) => {
  socket.onAny((event, ...args) => {

  });
});

// client
socket.onAny((event, ...args) => {
  // ...
});

Klingt es gut für dich? Hast du irgendwelche Vorschläge?

Hallo allerseits!

Steckdose. [email protected] und Sockel. [email protected] sind aus. Sie können sie mit npm i socket.io<strong i="10">@beta</strong> socket.io-client@beta testen.

Wir planen, 3.0.0 bis nächste Woche zu veröffentlichen. Der Migrationsleitfaden wurde erstellt: https://socket.io/docs/migrating-from-2-x-to-3-0/ (einige Details fehlen, wie die reservierten Ereignisse auf der Client-Seite)

Feedback ist wie immer willkommen!

Ich habe Zweifel, ich weiß nicht, ob hier der richtige Ort dafür ist, aber es ist möglich, die Socket-ID bei der Verbindung zu definieren, um beispielsweise die Client-ID von db zu verwenden? Das Ändern der "id"-Prop des Socket-Objekts in der Verbindungs-Middleware führt zur Synchronisierung mit dem Client?

@darrachequesne Danke für das RC4-Update.
Mit Version 3.0.0.rc4 - 2 Fragen:

1. Was ist der beste Weg, um die Anzahl oder Liste der Steckdosen (Clients) in einem Raum zu erhalten?
2. Wie bekomme ich am besten eine Liste aller aktuellen Zimmer?

Ich werde in den nächsten Tagen viele Tests mit rc4 durchführen.

Nochmals vielen Dank für all Ihre harte Arbeit.

@ferco0 derzeit nicht möglich, die Socket#id wird hier generiert . Was passiert in Ihrem Beispiel (Client-ID von db), wenn derselbe Benutzer einen neuen Tab öffnet? (da die Socket#id eindeutig sein muss)

@szarkowicz

1. Was ist der beste Weg, um die Anzahl oder Liste der Steckdosen (Clients) in einem Raum zu erhalten?

io.allSockets() => alle Socket-IDs abrufen (funktioniert mit mehreren Servern) (na ja, sobald der Redis-Adapter aktualisiert ist)
io.in("room1").allSockets() => Alle Socket-IDs im Raum abrufen

(in Socket.IO v2 hieß es io.clients() )

1. Wie bekomme ich am besten eine Liste aller aktuellen Zimmer?

Dafür gibt es derzeit keine API, abgesehen vom Eingraben in den Adapter: io.of("/").adapter.rooms ( hier )

Außerdem verfügt der Redis-Adapter über eine allRooms -Methode, die sich jedoch nicht in der öffentlichen API widerspiegelt.

Okay, ich weiß die Informationen sehr zu schätzen, um die Kunden und Räume für beide mit Redis und Non Redis zu bekommen. Ich werde wahrscheinlich nur mit socket.io v3 testen, bis der Redis-Adapter aktualisiert ist.

Migrieren Sie auf Webpack 4 (oder einen anderen Bundler, falls erforderlich)

Alternativ können Sie sich auch https://github.com/formium/tsdx ansehen.
Ich wollte vor einigen Monaten mit tsdx eine Neufassung von socket.io & engine.io in Typescript pushen, fand aber keine Zeit dafür :smile:

:rocket: Socket.IO v3.0.0 ist da! :rocket: Die Release Notes finden Sie hier: https://socket.io/blog/socket-io-3-release/

Danke an alle Beteiligten in diesem Thread für eure Ideen/Feedback :heart:

@darrachequesne , das macht für mich alles Sinn. Ich habe das Thema vergessen bzgl. asynchrone Middleware (in meinem aktuellen Projekt haben wir für jede Express-Route eine wrap() -Funktion erstellt, um genau dieses Problem zu lösen, damit keine Fehler durchs Raster fallen).

Danke für alle Verbesserungen!

Klingt es gut für dich? Hast du irgendwelche Vorschläge?

asynchrone Middleware

@michaelegregious könntest du bitte eine Funktionsanfrage dafür öffnen? Danke!

Ich werde dieses Thema jetzt schließen. Diskussion über die Veröffentlichung: https://github.com/socketio/socket.io/discussions/3674