salles socket.io ou espace de noms?

163

J'étudie nodejs / socket.io pour le chat en temps réel, et j'ai besoin de quelques conseils pour implémenter des salles.

Qu'est-ce qui est mieux, en utilisant un espace de noms ou en utilisant la fonction de salle pour isoler complètement des groupes de chatteurs les uns des autres?

quelle est la vraie différence technique entre les salles et l'espace de noms?

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

node.js socket.io

— Joseph
source

216

Voici ce que les espaces de noms et les salles ont en commun (socket.io v0.9.8 - veuillez noter que la v1.0 impliquait une réécriture complète, donc les choses pourraient avoir changé):

Les espaces de noms ( io.of ('/ nsp') ) et les rooms ( socket.join ('room') ) sont créés côté serveur
Plusieurs espaces de noms et plusieurs salles partagent la même connexion (WebSocket)
Le serveur transmettra des messages sur le fil uniquement aux clients qui se sont connectés / ont rejoint un nsp / room, c'est-à-dire que ce n'est pas seulement un filtrage côté client

Les différences :

les espaces de noms sont connectés par le client en utilisantio.connect(urlAndNsp) (le client ne sera ajouté à cet espace de noms que s'il existe déjà sur le serveur)
les salles ne peuvent être jointes que côté serveur (bien que la création d'une API côté serveur pour permettre aux clients de se joindre soit simple)
les espaces de noms peuvent être protégés par autorisation
l'autorisation n'est pas disponible avec les salles , mais une autorisation personnalisée pourrait être ajoutée à l'API susmentionnée, facile à créer sur le serveur, au cas où l'on serait déterminé à utiliser des salles
les salles font partie d'un espace de noms (par défaut, l'espace de noms «global»)
les espaces de noms sont toujours enracinés dans la portée globale

Pour ne pas confondre le concept avec le nom (room ou namespace), j'utiliserai compartiment pour faire référence au concept, et les deux autres noms pour les implémentations du concept. Alors si tu

besoin d'une autorisation par compartiment , les espaces de noms pourraient être la voie la plus simple à emprunter
si vous voulez des compartiments hiérarchisés (2 couches max), utilisez un combo espace de noms / pièce
si votre application côté client se compose 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 des espaces de noms.

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

N'ayant pas réellement évalué cela, il me semble que si vous avez juste besoin de simples compartiments dans votre projet pour séparer et regrouper les messages, l'un ou l'autre convient.

Je ne sais pas si cela répond à votre question, mais la recherche qui a mené à cette réponse m'a au moins aidé à voir plus clair.

— Eugène Beresovsky
source

5

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

— Xeroxoid

2

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

— Gonzalo Bahamondez

1

Pouvons-nous dire que l'espace de noms est une certaine zone de mon application Web et héberger un groupe de clients dans cette zone?

— Onaiggac

Pouvez-vous ajouter quelque chose à propos de la déconnexion d'une salle / espace de noms. Que leur arrive-t-il lorsque le client se déconnecte ou perd temporairement la connexion? Voici ce qui est écrit: lors de la déconnexion, les prises quittent automatiquement tous les canaux dont elles faisaient partie et aucun démontage particulier n'est nécessaire de votre part. Une chaîne est-elle la même que votre compartiment ?

— Flétrissement du

67

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 lien ): bien qu'il soit théoriquement possible de créer des espaces de noms dynamiquement 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, en revanche, 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 salles.

— Julio Garcia
source

3

J'aime ça! Espaces de noms - Connexions prédéfinies. Chambres - Connexions dynamiques

— Nandakumar

16

Cela dépend de ce que tu veux faire.

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

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

Exemple d'utilisation:

salles: chat privé.
namespaces: le chat de la page.

2

Les salles et les espaces de noms segmentent la communication et regroupent les prises individuelles.

Une diffusion vers une salle ou un espace de noms n'atteindra pas tout le monde, mais uniquement les membres.

La différence entre les espaces de noms et les salles est la suivante:

Espaces de noms: sont gérés dans le frontend, ce qui signifie que l'utilisateur, ou un attaquant, se joint à travers le frontend et la jonction et la déconnexion sont gérées ici.
Salles: sont gérées dans le backend, ce qui signifie que le serveur attribue les salles de connexion et de sortie.

La différence est principalement qui les gère

Pour décider quoi utiliser, vous devez décider si la segmentation doit être gérée dans le frontend ou dans le backend

— Zardilior
source

0

Les espaces de noms vous permettent de créer des objets avec le même nom, mais ils seraient séparés car ils vivront dans des espaces de noms différents, également appelés étendues.

C'est le même processus de réflexion que vous devriez avoir avec les espaces de noms Socket.IO. Si vous créez une application Web Node modulaire, vous souhaiterez créer un espace de noms entre les différents modules. Si vous regardez notre code d'espace de noms, vous verrez que nous avons pu écouter exactement les mêmes événements 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 noms / xxx sont différents. Par exemple, si vous aviez un système de discussion et de commentaires sur votre site et que vous vouliez que les deux soient en temps réel, vous pourriez chacun de l'espace de noms. Cela vous permet de créer une application Socket.IO entière qui ne vit que dans son propre contexte.

Cela serait également vrai si vous construisiez quelque chose à emballer et à installer. 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 y écouter. Cela vous permet de ne pas marcher sur les orteils d'un développeur qui utilise votre package.

Les espaces de noms nous permettent de créer des connexions dans différents contextes. Nous pouvons comparer cela à des salles, qui nous permettent de regrouper les connexions, nous pouvons alors avoir la même connexion pour rejoindre d'autres salles.

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

— faridcs
source