What is the point of rooms in socket.io?

Question

I was wondering what the purpose of rooms is. See: https://socket.io/docs/rooms-and-namespaces/

You can basically mimic join and leave with just socket.on and socket.off

Take for example:

(no room)

client:

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

server:

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

This will now listen to the "chat" and I can turn it off using socket.off("chat")

---

Now I do something similar but with a room:

client:

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

server:

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)
})

Now if I send a message to waiting room chat but a socket hasn't joined the room, it won't receive it. But what advantage does the second method have over the first?

Answer 1

Rooms are a tool in socket.io servers for keeping track of groups of connected users. You can then iterate the sockets in a room or broadcast to all of them. There's really nothing more to them than that. The server can put a socket into a room or remove one from a room. When a socket disconnects, it is automatically removed from all rooms it is in.

Each socket is also automatically put into a room whose name is constructed from its socket.id. That allows socket.io to send to any socket when you only have its id.

Your scheme for using only messages and then letting each client decide which messages to listen to is a client-driven scheme (client decides which messages to pay attention to) as opposed to a server-driven scheme and it probably doesn't scale as well because it requires you to send all messages to all clients so that all clients have a chance to listen to them all. Rooms, on the other hand, are a server-driven scheme where the server keeps track (in advance) of which sockets are in which group and only sends messages to the clients that should get those messages. The server both controls things and does it more efficiently.

Plus, in some cases, you can't leave it up to the client to decide what it's allowed to listen to. Imagine you have a chat server that sets up private 1-on-1 chat sessions. In that case, you can't have any circumstance where clientA is allowed to listen in on chat messages for some other chat session. To enforce that, the server has to ONLY send chat messages to the pairwise participants. This is a feature that rooms would be very useful for and your scheme would not.

Answer 2

Rooms are a logical grouping construct and have many benefits out of the box for developers using websockets:

1. Rooms make it easier to broadcast to a given set of clients, without referring to individual socket ids of each client.

2. A client can be or not be in a room, while staying connected. Hence rooms provide logical "subscription" to the event topics/channels being broadcasted by the server.

3. Some rooms may be even protected or require higher access levels, this can also be simulated by having client send a "join" request with credentials.

4. In multiplayer games, each game session or game area/zone is logically equivalent of a room.

5. When you are running a cluster of server instances, rooms (with help of socket.io bridge adapters) can even group clients connected to different server instances.