Welche WebSocket-Bibliothek soll mit Node.js verwendet werden?

Question

Derzeit gibt es eine Vielzahl von WebSocket-Bibliotheken für node.js, die beliebtesten scheinen zu sein:

• https://github.com/Worlize/WebSocket-Node
• https://github.com/einaros/ws
• https://github.com/LearnBoost/engine.io
• https://github.com/learnboost/socket.io
• https://github.com/sockjs

Leider finde ich keine konkreten Vergleiche zwischen ihnen... Angeblich war Socket.io großartig, aber ist ziemlich veraltet und hat fehlerhafte Builds. Sowohl ws als auch websocket-node behaupten, dass sie die schnellsten sind. Engine.io scheint neu zu sein, aber deutlich schwerer als die leichteren Alternativen.

Es wäre großartig, wenn wir oder jemand anderes eine Antwort zusammenstellen könnte, die als Leitfaden dient, welche Socket-Bibliothek wann verwendet werden soll und einen Vergleich zwischen ihnen bietet.

Answer 1

Starten Sie den Ball mit dieser Community-Wiki-Antwort. Fühlen Sie sich frei, mich zu bearbeiten mit Ihren Verbesserungen.

• ws WebSocket-Server und Client für node.js. Eines der schnellsten Libraries, wenn nicht das schnellste.

• websocket-node WebSocket-Server und Client für node.js

• websocket-driver-node WebSocket-Server und Client-Protokollanalyse für node.js - verwendet in faye-websocket-node

• faye-websocket-node WebSocket-Server und Client für node.js - verwendet in Faye und Sockjs

• socket.io WebSocket-Server und Client für node.js + Client für Browser + (Version 0 hat die neuesten bis zu den ältesten Fallbacks, Version 1 von Socket.io verwendet engine.io) + Kanäle - verwendet in stack.io. Die Client-Bibliothek versucht, nach einer Trennung erneut eine Verbindung herzustellen.

• sockjs WebSocket-Server und Client für node.js und andere + Client für Browser + neueste bis älteste Fallbacks

• faye WebSocket-Server und Client für node.js und andere + Client für Browser + Fallbacks + Unterstützung für andere serverseitige Sprachen

• deepstream.io clusterverfähiger Echtzeitserver, der WebSockets & TCP-Verbindungen verarbeitet und Daten-Synchronisierung, Pub/Sub und Anforderung/Antwort bereitstellt

• socketcluster WebSocket-Servercluster, der alle CPU-Kerne auf Ihrem Rechner nutzt. Wenn Sie beispielsweise eine xlarge Amazon EC2-Instanz mit 32 Kernen verwenden, könnten Sie fast 32-mal den Verkehr einer einzelnen Instanz bewältigen.

• primus Bietet eine gemeinsame API für die meisten oben genannten Bibliotheken für einfaches Umschalten + Stabilitätsverbesserungen für alle von ihnen.

Wann zu verwenden:

• Verwenden Sie die grundlegenden WebSocket-Server, wenn Sie die nativen WebSocket-Implementierungen auf der Clientseite verwenden möchten, Achten Sie auf die Browser-Inkompatibilitäten

• Verwenden Sie die Fallback-Bibliotheken, wenn Ihnen die Browser-Fallbacks wichtig sind.

• Verwenden Sie die umfangreichen Bibliotheken, wenn Ihnen die Kanäle wichtig sind.

• Verwenden Sie Primus, wenn Sie keine Ahnung haben, was Sie verwenden sollen, keine Lust haben, Ihre Anwendung neu zu schreiben, wenn Sie aufgrund sich ändernder Projektanforderungen das Framework wechseln müssen oder zusätzliche Verbindungsstabilität benötigen.

Wo zu testen:

Firecamp ist eine GUI-Testumgebung für SocketIO, WS und alle wichtigen Echtzeit-Technologien. Debuggen Sie die Echtzeit-Ereignisse, während Sie sie entwickeln.

Answer 2

Aktualisierung: Diese Antwort ist veraltet, da seitdem neuere Versionen der genannten Bibliotheken veröffentlicht wurden.

Socket.IO v0.9 ist veraltet und ein wenig fehlerhaft, und Engine.IO ist der vorläufige Nachfolger. Socket.IO v1.0 (der bald veröffentlicht wird) wird Engine.IO verwenden und wesentlich besser sein als v0.9. Ich würde empfehlen, Engine.IO zu verwenden, bis Socket.IO v1.0 veröffentlicht wird.

"ws" unterstützt kein Fallback, daher funktioniert es nicht, wenn der Browser des Clients Websockets nicht unterstützt, im Gegensatz zu Socket.IO und Engine.IO die Long-Polling usw. verwenden, wenn Websockets nicht verfügbar sind. Allerdings scheint "ws" derzeit die schnellste Bibliothek zu sein.

Siehe meinen Artikel, der Socket.IO, Engine.IO und Primus vergleicht: https://medium.com/p/b63bfca0539

Answer 3

Npm ws war die Antwort für mich. Ich fand es weniger aufdringlich und geradliniger. Außerdem war es auch trivial, Websockets mit Rest-Diensten zu mischen. Habe einfachen Code in diesem Beitrag geteilt.

var WebSocketServer = require("ws").Server;
var http = require("http");
var express = require("express");
var port = process.env.PORT || 5000;

var app = express();
    app.use(express.static(__dirname+ "/../"));
    app.get('/someGetRequest', function(req, res, next) {
       console.log('Empfangen der GET-Anfrage');
    });
    app.post('/somePostRequest', function(req, res, next) {
       console.log('Empfangen der POST-Anfrage');
    });
    app.listen(80); //Port 80 muss als root ausgeführt werden

    console.log("App hört auf %d ", 80);

var server = http.createServer(app);
    server.listen(port);

console.log("HTTP-Server hört auf %d", port);

var userId;
var wss = new WebSocketServer({server: server});
    wss.on("connection", function (ws) {

    console.info("Websocket-Verbindung geöffnet");

    var timestamp = new Date().getTime();
    userId = timestamp;

    ws.send(JSON.stringify({msgType:"onOpenConnection", msg:{connectionId:timestamp}}));

    ws.on("message", function (data, flags) {
        console.log("Websocket hat eine Nachricht erhalten");
        var clientMsg = data;

        ws.send(JSON.stringify({msg:{connectionId:userId}}));

    });

    ws.on("close", function () {
        console.log("Websocket-Verbindung geschlossen");
    });
});
console.log("Websocket-Server erstellt");