web-dev-qa-db-fra.com

Engine.io ou SockJS, lequel choisir?

J'ai récemment rencontré des problèmes avec Socket.io concernant les fuites de mémoire et les problèmes de mise à l'échelle. Ma décision d'utiliser Socket.io a été prise il y a plus d'un an alors qu'elle était sans aucun doute la meilleure bibliothèque à utiliser.

Maintenant que Socket.io cause beaucoup de problèmes, j'ai passé du temps à chercher des alternatives qui sont devenues disponibles entre-temps et je pense que Engine.io et SockJS me conviennent généralement bien. Cependant, à mon avis, les deux présentent certains inconvénients et je ne sais pas lequel choisir.

Engine.io est fondamentalement la version légère parfaite de Socket.io qui ne contient pas toutes les fonctionnalités dont je n'ai pas besoin de toute façon. J'ai déjà écrit ma propre logique de reconnexion et de pulsation pour Socket.io, car je n'étais pas satisfait des logiques par défaut et je n'ai jamais eu l'intention d'utiliser des salles ou d'autres fonctionnalités offertes par Socket.io.

Mais - à mon avis - le principal inconvénient de Engine.io est la façon dont les connexions sont établies. Les clients commencent par une interrogation jsonp plus lente et sont mis à niveau s'ils prennent en charge de meilleurs transports. Le fait que les clients qui prennent en charge les websockets nativement (nombre croissant régulièrement) présente un inconvénient sous la forme d'une procédure de connexion plus longue et instable par rapport aux clients qui utilisent des navigateurs obsolètes, contredit mon sens de la façon dont il doit être géré.

SockJS d'autre part gère les connexions exactement comme je le voudrais. D'après ce que j'ai lu, il semble être assez stable alors que Engine.io a quelques problèmes en ce moment.

Mon application s'exécute derrière un routeur Nginx sur un seul domaine, donc je n'ai pas besoin de la fonctionnalité interdomaine offerte par SockJS. En raison de la fourniture de cette fonctionnalité, SockJS n'expose pas du tout les données de cookie du client. Jusqu'à présent, j'avais une autorisation à 2 facteurs avec Socket.io via un cookie ET un jeton de chaîne de requête et cela ne serait pas possible avec SockJS (avec Engine.io, ce serait le cas).

J'ai lu à peu près tout ce qui est disponible et les avantages et les inconvénients des deux, mais il semble qu'il n'y ait pas beaucoup de discussions ou de publications à ce jour, en particulier sur Engine.io (il n'y a que 8 questions étiquetées avec engine.io ici).

  • Laquelle des 2 bibliothèques préférez-vous et pour quelle raison? Les utilisez-vous en production?

  • Lequel sera probablement maintenu plus activement et pourrait avoir un avantage majeur sur l'autre à l'avenir?

websocketsocket.iocomparisonsockjsengine.io
34
1nsane

Avez-vous regardé Primus ? Il offre les exigences de cookies que vous mentionnez, il prend en charge toutes les bibliothèques major 'en temps réel'/websocket disponibles et est un projet assez actif. Pour moi, il semble également que le blocage des fournisseurs pourrait être un problème pour vous et Primus y répondrait.

Le fait qu'il utilise un système de plugins devrait également a) vous faciliter l'extension si nécessaire et b) peut en fait avoir un plugin communautaire qui fait déjà ce dont vous avez besoin .

Laquelle des 2 bibliothèques préférez-vous et pour quelle raison? Les utilisez-vous en production?

Je n'ai utilisé SockJS que via l'API Vert.x et c'est pour un projet interne que je considérerais la "production", mais pas une application grand public orientée production. Cela dit, cela a très bien fonctionné.

Lequel sera probablement maintenu plus activement et pourrait avoir un avantage majeur sur l'autre à l'avenir?

Un simple examen de l'historique des validations de Engine.io et SockJS , et le fait qu'Auttomatic supporte Engine.io me donne tendance à penser qu'il sera plus stable, par exemple une plus longue période de temps, mais bien sûr, c'est discutable. L'examen des problèmes pour Engine.io et SockJS est un autre bon endroit pour évaluer, mais comme ils sont tous deux répartis sur plusieurs dépôts, il doit être pris avec un grain de sel . Je ne sais pas où/comment Automattic utilise Engine/Socket.io, mais si c'est dans WordPress.com ou l'un de leurs plugins, il a des tests de combat de production à grande échelle substantiels.

Modifier: modifiez la réponse pour refléter la prise en charge des cookies confirmée par l'auteur de Primus dans les commentaires ci-dessous

5
brennebeck

Je voudrais vous rediriger vers ce fil de discussion (assez détaillé) sur SockJS et Engine.io

https://groups.google.com/forum/#!topic/sockjs/WSIdcY14ciI

Fondamentalement,

SockJS détecte les transports en cours avant de marquer la connexion comme ouverte. Engine.io ouvrira immédiatement la connexion et la mettra à niveau ultérieurement.

flash , l'une des solutions de rechange Engine.io (et pas présente dans SockJS) se charge lentement et dans les environnements derrière les proxys, le délai d'expiration est de 3 secondes.

SockJS n'utilise pas de flash et n'a donc pas besoin de contourner ce problème.

SockJS effectue la mise à niveau au démarrage. Après cela, vous avez une expérience cohérente. Vous envoyez ce que vous envoyez, vous recevez ce que vous recevez.

Aussi, pour autant que je sache, la bibliothèque engine.io-client (côté client) pour engine.io, ne prend pas en charge les builds requirejs, c'est donc un autre point négatif. (SockJS se construit parfaitement).

1
kumarharsh

Vous pouvez également considérer node-walve . WebSocket de base complet. Extrêmement performant car entièrement basé sur le flux.

Exemple d'utilisation:

walve.createServer(function(wsocket) {
  wsocket.on('incoming', function(incoming) {
    incoming.pipe(process.stdout, { end: false });
  });
}).listen(server);

Ce n'est peut-être pas le meilleur choix si vous ne vous sentez pas en sécurité dans l'environnement nodejs (par exemple, l'extension de prototypes pour le sucre API), contribuant au projet (bien que le code soit plus lisible en tant que socket.io).

0
bodokaiser