web-dev-qa-db-fra.com

Quelle bibliothèque websocket utiliser avec Node.js?

Actuellement, il existe un pléthore de bibliothèques websocket pour node.js, les plus populaires semblent être:

Cependant, je ne trouve aucune comparaison concrète solide entre eux ... Apparemment, Socket.io était génial, mais il est devenu assez désuet et présente des versions défaillantes. Ws et websocket-node prétendent qu'ils sont les plus rapides. Et engine.io semble nouveau, mais beaucoup plus lourd que les plus légers.

Il serait étonnant que nous, ou quelqu'un, puissions rassembler une réponse qui serve de guide sur la bibliothèque de socket à utiliser et à quel moment, ainsi que sur une comparaison entre elles.

node.jswebsocketsocket.iosockjsengine.io
411
balupton

Lancer le bal avec cette réponse wiki de la communauté . N'hésitez pas à modifiez-moi avec vos améliorations.

  • ws serveur WebSocket et client pour node.js. Une des bibliothèques les plus rapides, sinon la plus rapide.

  • websocket-node serveur WebSocket et client pour node.js

  • websocket-driver-node Serveur WebSocket et analyseur de protocole client node.js - utilisés dans faye-websocket-node

  • faye-websocket-node serveur et client WebSocket pour node.js - utilisé dans faye et sockjs

  • socket.io Serveur WebSocket et client pour node.js + client pour navigateurs + (v0 a les plus anciennes replis, la v1 de Socket.io utilise engine.io) + canaux - utilisés dans stack.io. La bibliothèque cliente tente de se reconnecter lors de la déconnexion.

  • sockjs serveur WebSocket et client pour node.js et autres + client pour navigateurs + solutions de secours les plus récentes à les plus anciennes

  • faye serveur WebSocket et client pour node.js et autres + client pour navigateurs + solutions de secours + prise en charge d'autres langues côté serveur

  • deepstream.io serveur en temps réel clusterable qui gère les connexions WebSockets & TCP et fournit la synchronisation des données, la publication/la publication et la demande/réponse

  • socketcluster Groupe de serveurs WebSocket qui utilise tous les cœurs de processeur de votre machine. Par exemple, si vous utilisiez une instance xlarge Amazon EC2 avec 32 cœurs, vous seriez en mesure de gérer près de 32 fois le trafic sur une seule instance.

  • primus Fournit une API commune à la plupart des bibliothèques ci-dessus pour faciliter la commutation et améliorer la stabilité de toutes.

Quand utiliser:

  • utilisez les serveurs WebSocket de base lorsque vous souhaitez utiliser les implémentations WebSocket natives sur le côté client, méfiez-vous des incompatibilités de navigateur

  • utilisez les bibliothèques de secours lorsque vous vous souciez des secours du navigateur

  • utilisez les bibliothèques complètes lorsque vous vous souciez des canaux

  • utilisez primus lorsque vous ne savez pas quoi utiliser, que vous n'êtes pas d'humeur à réécrire votre application lorsque vous devez changer de framework en raison de la modification des exigences du projet ou pour renforcer la stabilité de la connexion.

Où tester:

Firecamp est un environnement de test graphique pour SocketIO, WS et toutes les technologies majeures en temps réel. Déboguez les événements en temps réel pendant que vous les développez.

375
balupton

Mise à jour: Cette réponse est obsolète car les nouvelles versions des bibliothèques mentionnées sont publiées depuis.

Socket.IO v0.9 est obsolète et un peu bogué, et Engine.IO en est le successeur provisoire. Socket.IO v1.0 (qui sera publié bientôt) utilisera Engine.IO et sera bien meilleur que v0.9. Je vous recommanderais d'utiliser Engine.IO jusqu'à la publication de Socket.IO v1.0.

"ws" ne prend pas en charge le repli. Par conséquent, si le navigateur client ne prend pas en charge les websockets, cela ne fonctionnera pas, contrairement à Socket.IO et Engine.IO, qui utilisent l'interrogation longue, etc. si les websockets ne sont pas disponibles. Cependant, "ws" semble être la bibliothèque la plus rapide du moment.

Voir mon article comparant Socket.IO, Engine.IO et Primus: https://medium.com/p/b63bfca0539

39
Deniz Ozger

npm ws était la réponse pour moi. Je l'ai trouvé moins intrusif et plus simple. Il était également trivial de mélanger des Websockets avec des services de repos. Code simple partagé sur ce post.

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('receiving get request');
    });
    app.post('/somePostRequest', function(req, res, next) {
       console.log('receiving post request');
    });
    app.listen(80); //port 80 need to run as root

    console.log("app listening on %d ", 80);

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

console.log("http server listening on %d", port);

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

    console.info("websocket connection open");

    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 received a message");
        var clientMsg = data;

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


    });

    ws.on("close", function () {
        console.log("websocket connection close");
    });
});
console.log("websocket server created");
27
MFAL