web-dev-qa-db-fra.com

Quel est l'intérêt des pièces dans socket.io?

Je me demandais quel était le but des chambres. Voir: https://socket.io/docs/rooms-and-namespaces/

Vous pouvez essentiellement imiter join et leave avec seulement socket.on Et socket.off

Prends pour exemple:

(pas de chambre)

client:

socket.on('chat', (data) => {
    console.log("chat received", data)
    $(this.$refs.chatBox).append(`
        <div>
            ${data}
        </div>
    `)
})

serveur:

socket.on('chat', function (id, msg) {
    console.log("id:", id, 'message:', msg)
    socket.broadcast.emit('chat', msg);
    // io.emit('chat', msg)
})

Cela va maintenant écouter le "chat" Et je peux le désactiver en utilisant socket.off("chat")

Maintenant je fais quelque chose de similaire mais avec une pièce:

client:

// to join
socket.emit('waiting room', socket.id)
// to message
socket.emit('waiting room chat', { msg: this.$refs.waiting_input.value })

serveur:

socket.on('waiting room', function (id) {
    console.log("socket has joined the waiting room", id);
    socket.join("waiting room")
})

socket.on("waiting room chat", function(payload) {
    console.log("waiting room chat:", payload.msg)
    // io.to("waiting room").emit('waiting room', payload.msg)
    socket.broadcast.to("waiting room").emit('waiting room', payload.msg)
})

Maintenant, si j'envoie un message à waiting room chat Mais qu'un socket n'a pas rejoint la salle, il ne le recevra pas. Mais quel avantage la seconde méthode a-t-elle sur la première?

node.jswebsocketssocket.io
5
A. Lau

Les salles sont un outil des serveurs socket.io pour garder une trace des groupes d'utilisateurs connectés. Vous pouvez ensuite parcourir les prises dans une pièce ou les diffuser à toutes. Il n'y a vraiment rien de plus pour eux que ça. Le serveur peut mettre une prise dans une pièce ou en retirer une d'une pièce. Lorsqu'une prise se déconnecte, elle est automatiquement supprimée de toutes les pièces dans lesquelles elle se trouve.

Chaque prise est également placée automatiquement dans une pièce dont le nom est construit à partir de son socket.id. Cela permet à socket.io d'envoyer à n'importe quel socket lorsque vous n'avez que son identifiant.

Votre schéma pour utiliser uniquement des messages et laisser chaque client décider des messages à écouter est un schéma piloté par le client (le client décide des messages auxquels il faut prêter attention) par opposition à un schéma piloté par le serveur et il ne se modifie probablement pas aussi bien car il vous oblige à envoyer tous les messages à tous les clients afin que tous les clients aient la possibilité de les écouter tous. Les chambres, d'autre part, sont un schéma piloté par le serveur où le serveur garde une trace (à l'avance) des sockets dans quel groupe et envoie uniquement des messages aux clients qui devraient recevoir ces messages. Le serveur contrôle à la fois les choses et le fait plus efficacement.

De plus, dans certains cas, vous ne pouvez pas laisser au client le soin de décider ce qu'il est autorisé à écouter. Imaginez que vous ayez un serveur de chat qui met en place des sessions de chat privées. Dans ce cas, vous ne pouvez avoir aucune circonstance où clientA est autorisé à écouter les messages de discussion pour une autre session de discussion. Pour appliquer cela, le serveur doit UNIQUEMENT envoyer des messages de discussion aux participants par paire. C'est une fonctionnalité pour laquelle les chambres seraient très utiles et votre schéma ne le serait pas.

7
jfriend00

Les salles sont une construction de regroupement logique et présentent de nombreux avantages prêts à l'emploi pour les développeurs utilisant des websockets:

  1. Les salles facilitent la diffusion vers un ensemble donné de clients, sans se référer aux identifiants de socket individuels de chaque client.

  2. Un client peut être ou non dans une chambre, tout en restant connecté. Par conséquent, les salles fournissent un "abonnement" logique aux sujets/canaux d'événements diffusés par le serveur.

  3. Certaines salles peuvent même être protégées ou nécessitent des niveaux d'accès plus élevés, cela peut également être simulé en demandant au client d'envoyer une demande de "jointure" avec des informations d'identification.

  4. Dans les jeux multijoueurs, chaque session de jeu ou zone/zone de jeu est logiquement équivalente à une salle.

  5. Lorsque vous exécutez un cluster d'instances de serveur, les salles (à l'aide d'adaptateurs de pont socket.io) peuvent même regrouper les clients connectés à différentes instances de serveur.

3
S.D.