Faye 与 Socket.IO（和 Juggernaut）

发布于 2024-10-15 17:24:02 字数 777 浏览 13 评论 0原文

Socket.IO 似乎是最流行、最活跃的 WebSocket 模拟库。 Juggernaut 使用它来创建一个完整的发布/订阅系统。

Faye 也很受欢迎且活跃，并且拥有自己的 javascript 库，使其完整的功能可与 Juggernaut 相媲美。 Juggernaut 使用节点作为其服务器，而 Faye 可以使用节点或机架。 Juggernaut 使用 Redis 进行持久化（更正：它使用 Redis 进行发布/订阅），而 Faye 仅将状态保存在内存中。

以上一切准确吗？
Faye 说它实现了 Bayeux - 我认为 Juggernaut 不会这样做 - 是因为 Juggernaut 的级别较低（IE，我可以使用 Juggernaut 实现 Bayeux），
如果 Faye 愿意的话，可以切换到使用 Socket.IO 浏览器 javascript 库吗？或者他们的 javascript 库做了根本不同的事情吗？
这些项目之间是否存在其他建筑/设计/理念差异？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

蓝戈者 2024-10-22 17:24:02

披露：我是《Faye》的作者。

关于 Faye，您所说的一切都是真实的。
Faye 实现了 Bayeux 的大部分功能，目前唯一缺少的是服务渠道，我尚未确信其有用性。特别是Faye被设计为与Bayeux的CometD参考实现兼容，这对以下内容有很大影响。
从概念上讲，是的：Faye可以使用Socket.IO。实际上，这存在一些障碍：
- 我不知道 Socket.IO 需要什么样的服务器端支持，以及 Faye 客户端（记住 Node 和 Ruby 中有服务器端客户端）能够与任何 Bayeux 服务器通信的要求（以及 Faye 服务器到任何 Bayeux 客户端）可能会破坏交易。
- Bayeux 对服务器和客户端支持某些传输类型有具体要求，并说明了如何协商使用哪一种。它还指定它们的使用方式，例如 XHR 请求的 Content-Type 如何影响其内容的解释方式。
- 对于某些类型的错误处理，我需要直接访问传输，例如 Node WebSocket 死机后客户端重新连接时重新发送消息。
- 如果我有任何错误，请纠正我 - 这是基于对 Socket.IO 文档的粗略扫描。
Faye 只是 pub/sub，它只是基于稍微复杂一点的协议，并且内置了很多细节：
- 服务器端和客户端扩展
- 通道路由上的通配符模式匹配
- 自动重新连接，例如当 WebSocket 失效或服务器离线时
- 客户端适用于所有浏览器、手机以及 Node 和 Ruby 上的服务器端

Faye 上的服务器端上运行与 Juggernaut 相比，它看起来要复杂得多，因为 Juggernaut 委托更多，例如，它将传输协商委托给 Socket.IO，将消息路由委托给 Redis。这些都是很好的决定，但我决定使用贝叶意味着我必须自己做更多的工作。

至于设计理念，Faye 的首要目标是它应该适用于任何可以使用 Web 的地方，并且应该非常容易上手。上手真的很简单，但它的可扩展性意味着它可以以非常强大的方式进行定制，例如，您可以通过添加身份验证扩展将其变成服务器到客户端的推送服务（即停止任意客户端推送）。

还正在进行使其在服务器端更加灵活的工作。我正在考虑添加集群支持，并使核心 pub-sub 引擎可插拔，以便您可以使用 Faye 作为另一个 pub-sub 系统（如 Redis 或 AMQP）的无状态 Web 前端。

我希望这对您有所帮助。

Disclosure: I am the author of Faye.

Regarding Faye, everything you've said is true.
Faye implements most of Bayeux, the only thing missing right now is service channels, which I've yet to be convinced of the usefulness of. In particular Faye is designed to be compatible with the CometD reference implementation of Bayeux, which has a large bearing on the following.
Conceptually, yes: Faye could use Socket.IO. In practise, there are some barriers to this:
- I've no idea what kind of server-side support Socket.IO requires, and the requirement that the Faye client (there are server-side clients in Node and Ruby, remember) be able to talk to any Bayeux server (and the Faye server to any Bayeux client) may be deal-breaker.
- Bayeux has specific requirements that servers and clients support certain transport types, and says how to negotiate which one to use. It also specifies how they are used, for example how the Content-Type of an XHR request affects how its content is interpreted.
- For some types of error handling I need direct access to the transport, for example resending messages when a client reconnects after a Node WebSocket dies.
- Please correct me if I've got any of this wrong - this is based on a cursory scan of the Socket.IO documentation.
Faye is just pub/sub, it's just based on a slightly more complex protocol and has a lot of niceties built in:
- Server- and client-side extensions
- Wildcard pattern-matching on channel routes
- Automatic reconnection, e.g. when WebSockets die or the server goes offline
- The client works in all browsers, on phones, and server-side on Node and Ruby

Faye probably looks a lot more complex compared to Juggernaut because Juggernaut delegates more, e.g. it delegates transport negotiation to Socket.IO and message routing to Redis. These are both fine decisions, but my decision to use Bayeux means I have to do more work myself.

As for design philosophy, Faye's overriding goal is that it should work everywhere the Web is available and should be absolutely trivial to get going with. I'ts really simple to get started with but its extensibility means it can be customized in quite powerful ways, for example you can turn it into a server-to-client push service (i.e. stop arbitrary clients pushing to it) by adding authentication extensions.

There is also work underway to make it more flexible on the server side. I'm looking at adding clustering support, and making the core pub-sub engine pluggable so you could use Faye as a stateless web frontend for another pub-sub system like Redis or AMQP.

I hope this has been helpful.

回复收藏 0 原文

独享拥抱 2024-10-22 17:24:02

AFAIK，是的，除了 Juggernaut 仅将 Redis 用于 Pubsub，而不是持久性这一事实之外。也意味着大多数语言的客户端库已经编写完成（因为它只需要一个 Redis 适配器）。
Juggernaut 没有实现 Bayeux，而是有一个非常简单的自定义 JSON 协议，
我不知道，但可能
Juggernaut 非常简单，并且设计就是这样的。虽然我没有使用过 Faye，但从文档来看它似乎比 PubSub 有更多的功能。基于 Socket.IO 构建也有其优势，几乎所有浏览器（桌面和移动）都支持 Juggernaut。

我对费伊的作者所说的话非常感兴趣。正如我所说，我还没有使用过它，很高兴知道它与 Juggernaut 相比如何。这可能是使用最好的工具来完成工作的情况。如果您需要 pubsub，Juggernaut 就能很好地满足您的需求。

回复收藏 0 原文