websocket - Faye 与 Socket.IO(和 Juggernaut)

Question

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

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

1. 以上内容准确吗？
2. Faye 表示它实现了 Bayeux -- 我认为 Juggernaut 不会这样做 -- 因为 Juggernaut 的级别较低(IE，我可以使用 Juggernaut 实现 Bayeux)
3. 如果 Faye 愿意的话，可以改用 Socket.IO 浏览器 JavaScript 库吗？或者他们的 javascript 库做了根本不同的事情吗？
4. 这些项目之间是否存在其他架构/设计/理念差异？

Answer 1

披露:我是 Faye 的作者。

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

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

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

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

我希望这对您有所帮助。