socket.io rooms or namespacing?

This is what namespaces and rooms have in common (socket.io v0.9.8 - please note that v1.0 involved a complete rewrite, so things might have changed):

• Both namespaces (io.of('/nsp')) and rooms (socket.join('room')) are created on the server side
• Multiple namespaces and multiple rooms share the same (WebSocket) connection
• The server will transmit messages over the wire only to those clients that connected to / joined a nsp / room, i.e. it's not just client-side filtering

The differences:

• namespaces are connected to by the client using io.connect(urlAndNsp) (the client will be added to that namespace only if it already exists on the server)
• rooms can be joined only on the server side (although creating an API on the server side to enable clients to join is straightforward)
• namespaces can be authorization protected
• authorization is not available with rooms, but custom authorization could be added to the aforementioned, easy-to-create API on the server, in case one is bent on using rooms
• rooms are part of a namespace (defaulting to the 'global' namespace)
• namespaces are always rooted in the global scope

To not confuse the concept with the name (room or namespace), I'll use compartment to refer to the concept, and the other two names for the implementations of the concept. So if you

• need per-compartment authorization, namespaces might be the easiest route to take
• if you want hierarchically layered compartments (2 layers max), use a namespace/room combo
• if your client-side app consists of different parts that (do not themselves care about compartments but) need to be separated from each other, use namespaces.

An example for the latter would be a large client app where different modules, perhaps developed separately (e.g. third-party), each using socket.io independently, are being used in the same app and want to share a single network connection.

Not having actually benchmarked this, it seems to me if you just need simple compartments in your project to separate and group messages, either one is fine.

Not sure if that answers your question, but the research leading up to this answer at least helped me see clearer.

It's an old question but after doing some research on the topic I find that the accepted answer is not clear on an important point. According to Guillermo Rauch himself (see link): although it is theoretically possible to create namespaces dynamically on a running app you use them mainly as predefined separate sections of you application. If, on the other hand you need to create ad hoc compartments, on the fly, to accommodate groups of users/connections, it is best to use rooms.

It depends what you wanna do.

The main difference is that rooms are harder to implement. You must make a method for join the rooms with each page reload.

With namespaces you just need to write var example = io.connect('http://localhost/example'); in your javascript client and client are automatically added in the namespaces.

Example of utilization:

• rooms: private chat.
• namespaces: the chat of the page.

Rooms and namespaces segment communication and group individual sockets.

A broadcast to a room or to a namespace will not reach everyone just the members.

The difference between namespaces and rooms is the following:

• Namespaces: are managed in the frontend meaning the user, or an attacker, joins through the frontend and the joining and disconnecting is managed here.
• Rooms: are managed in the backend, meaning the server assigns joining and leaving rooms.

The difference is mainly who manages them

To decide what to use you must decide if the segmentation should be managed in the frontend or in the backend