173 votes

salles socket.io ou namespacing ?

Je suis en train d'étudier nodejs/socket.io pour le chat en temps réel, et j'ai besoin de conseils pour la mise en œuvre des salles.

Qu'est-ce qui est le mieux, l'utilisation de l'espace de noms ou l'utilisation de la fonctionnalité de salle pour isoler complètement les groupes de bavards les uns des autres ?

Quelle est la véritable différence technique entre les salles et les espaces de noms ?

Y a-t-il une différence dans l'utilisation des ressources ?

231voto

Eugene Beresovksy Points 3852

C'est ce que font les espaces de noms et les pièces en commun (socket.io v0.9.8 - veuillez noter que la v1.0 a impliqué une réécriture complète, donc les choses peuvent avoir changé) :

  • Les deux espaces de noms ( io.of('/nsp') ) et les chambres ( socket.join('room') ) sont créés du côté du serveur
  • Espaces de noms multiples et pièces multiples partager la même connexion (WebSocket)
  • Le serveur transmettre des messages sur le fil uniquement aux clients qui se sont connectés à / ont rejoint un spn / une chambre, c'est-à-dire qu'il ne s'agit pas seulement d'un filtrage côté client

El différences :

  • sont connectés par le client en utilisant io.connect(urlAndNsp) (le client sera ajouté à cet espace de nom seulement s'il existe déjà sur le serveur)
  • les salles ne peuvent être jointes que du côté serveur (bien que la création d'une API côté serveur pour permettre aux clients de s'y joindre soit simple).
  • Les espaces de noms peuvent être autorisation protégée
  • l'autorisation n'est pas disponible avec les chambres mais des autorisations personnalisées peuvent être ajoutées à l'API susmentionnée, facile à créer sur le serveur, au cas où l'on voudrait utiliser des chambres.
  • les pièces font partie d'un espace de nom (par défaut, l'espace de nom "global")
  • Les espaces de noms sont toujours enracinés dans la portée globale.

Pour ne pas confondre le concept avec le nom (pièce ou espace de nom), j'utiliserai compartiment pour faire référence au concept, et les deux autres noms pour la mises en œuvre du concept. Ainsi, si vous

  • besoin de autorisation par compartiment les espaces de noms pourraient être la voie la plus facile à suivre.
  • si vous voulez compartiments hiérarchiquement superposés (2 couches maximum), utiliser une combinaison espace nom/chambre
  • si votre application côté client est constituée de différentes parties qui (ne se soucient pas elles-mêmes des compartiments mais) doivent être séparées les unes des autres, utilisez les espaces de noms.

Un exemple de ce dernier cas serait une grande application client où différents modules, peut-être développés séparément (par exemple, par un tiers), utilisant chacun socket.io indépendamment, sont utilisés dans la même application et veulent partager une seule connexion réseau.

Je n'ai pas fait d'étude comparative, mais il me semble que si vous avez juste besoin de compartiments simples dans votre projet pour séparer et grouper les messages, l'un ou l'autre est parfait.

Je ne sais pas si cela répond à votre question, mais les recherches qui ont conduit à cette réponse m'ont au moins aidé à y voir plus clair.

5 votes

Y a-t-il quelque chose de majeur qui a changé à ce sujet après la version de socket.io >= 1.0 ?

2 votes

Changements dans la dernière version, lire socket.io/docs/rooms-and-namespaces et cette réponse peut être utile pour comprendre les choses des chambres stackoverflow.com/questions/24041220/

1 votes

Pouvons-nous dire que l'espace de noms est une certaine zone de mon application web et y placer un groupe de clients ?

75voto

Julio Garcia Points 691

C'est une vieille question, mais après avoir fait quelques recherches sur le sujet, je trouve que la réponse acceptée n'est pas claire sur un point important. Selon Guillermo Rauch lui-même ( voir le lien ) : bien qu'il soit théoriquement possible de créer des espaces de noms de manière dynamique sur une application en cours d'exécution, vous les utilisez principalement comme des sections séparées prédéfinies de votre application. Si, par contre, vous avez besoin de créer des compartiments ad hoc, à la volée, pour accueillir des groupes d'utilisateurs/connexions, il est préférable d'utiliser des rooms.

3 votes

Vous aimez ! Namespaces - Connexions prédéfinies. Salles - Connexions dynamiques

21voto

Ça dépend de ce que tu veux faire.

La principale différence est que chambres sont plus difficiles à mettre en œuvre. Vous devez créer une méthode pour joindre les salles à chaque rechargement de la page.

Avec espaces de noms il suffit d'écrire var example = io.connect('http://localhost/example'); dans votre client javascript et client sont automatiquement ajoutés dans les espaces de noms.

Exemple d'utilisation :

  • salles : chat privé.
  • espaces de noms : le chat de la page.

5voto

zardilior Points 374

Les salles et les espaces de noms segmentent la communication et regroupent les sockets individuels.

Une diffusion dans une salle ou dans un espace de nom n'atteindra pas tout le monde, mais seulement les membres.

La différence entre les espaces de noms et les pièces est la suivante :

  • Les espaces de noms : sont gérés dans le front-end, ce qui signifie que l'utilisateur, ou un attaquant, se joint au front-end et que l'adhésion et la déconnexion sont gérées ici.
  • Salles : elles sont gérées en backend, c'est-à-dire que le serveur attribue les salles d'arrivée et de départ.

La différence réside principalement dans la personne qui les gère

Pour décider de ce qu'il faut utiliser, vous devez décider si la segmentation doit être gérée dans le front-end ou dans le back-end.

2voto

faridcs Points 367

Les espaces de noms vous permettent de créer des objets portant le même nom, mais ils seront distincts car ils vivront dans des espaces de noms différents, autrement appelés scopes.

C'est le même processus de réflexion que vous devriez avoir avec les espaces de noms Socket.IO. Si vous construisez une application web Node modulaire, vous voudrez créer des espaces de noms pour les différents modules. Si vous regardez notre code d'espace de noms, vous verrez que nous avons pu écouter les mêmes événements exacts dans différents espaces de noms. Dans Socket.IO, l'événement de connexion sur la connexion par défaut et l'événement de connexion sur un espace de nom /xxx sont différents. Par exemple, si vous avez un système de chat et de commentaires sur votre site et que vous voulez que les deux soient en temps réel, vous pouvez utiliser un espace de nom pour chacun. Cela vous permet de construire une application Socket.IO entière qui ne vit que dans son propre contexte.

Cela serait également vrai si vous construisiez un produit destiné à être emballé et installé. Vous ne pouvez pas savoir si quelqu'un utilise déjà certains événements dans l'espace de noms par défaut, vous devez donc créer le vôtre et l'écouter. Cela vous permet de ne pas marcher sur les plates-bandes des développeurs qui utilisent votre paquetage.

Les espaces de noms nous permettent de découper les connexions dans différents contextes. Nous pouvons comparer cela aux salles, qui nous permettent de regrouper des connexions et de faire en sorte qu'une même connexion puisse également rejoindre d'autres salles.

Les espaces de noms vous permettent de créer différents contextes dans lesquels Socket.IO peut travailler. Les chambres vous permettent de regrouper les connexions des clients à l'intérieur de ces contextes.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X