socket.io 房间或命名空间? [英] socket.io rooms or namespacing?

问题描述

我正在研究用于实时聊天的 nodejs/socket.io，我需要一些关于实现房间的建议.

I am investigating nodejs/socket.io for real time chat, and I need some advice for implementing rooms.

哪个更好，使用命名空间或使用房间功能来完全隔离彼此之间的聊天记录?

Which is better, using namespace or using the room feature to completely isolate grops of chatters from each other?

房间和命名空间之间真正的技术区别是什么?

what is the real technical difference between rooms and namespace?

是否存在资源使用差异?

Is there any resource usage difference?

推荐答案

这是命名空间和房间的共同点(socket.io v0.9.8 - 请注意 v1.0 涉及一个完整的重写，所以事情可能会改变):

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

• 两个命名空间(io.of('/nsp')) 和房间(socket.join('room')) 在服务器端创建
• 多个命名空间和多个房间共享相同的 (WebSocket) 连接
• 服务器将仅通过线路将消息传输到那些连接到/加入 nsp/房间的客户端，即它不仅仅是客户端过滤

• 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

差异:

• 命名空间由客户端使用 io.connect(urlAndNsp) 连接到(只有在服务器上已经存在该命名空间时，客户端才会被添加到该命名空间中)
• 房间只能在服务器端加入(尽管在服务器端创建一个 API 来让客户端加入很简单)
• 命名空间可以授权保护
• 授权不适用于房间，但可以将自定义授权添加到上述服务器上易于创建的 API 中，以防有人一心要使用房间
• 房间是命名空间的一部分(默认为全局"命名空间)
• 命名空间始终根植于全局范围

• 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

为了不将概念与名称(房间或命名空间)混淆，我将使用 compartment 来指代概念，另外两个名称用于 实现的概念.所以如果你

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

• 需要per-compartment 授权，命名空间可能是最简单的途径
• 如果您想要分层隔间(最多 2 层)，请使用命名空间/房间组合
• 如果您的客户端应用由不同的部分组成，这些部分(本身并不关心隔间，但)需要彼此分开，请使用命名空间.

• 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.

后者的一个例子是一个大型客户端应用程序，其中不同的模块，可能是单独开发的(例如第三方)，每个模块都独立使用 socket.io，在同一个应用程序中使用并希望共享单个网络连接.

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.

这篇关于socket.io 房间或命名空间?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！