Faye与Socket.IO（和Juggernaut）

Question

Socket.IO似乎是最流行和活跃的WebSocket仿真库。 Juggernaut使用它来创建完整的发布/订阅系统。

Faye也很流行，并有自己的JavaScript库，使其完整的功能可以与Juggernaut相媲美。 Juggernaut使用节点作为其服务器，而Faye可以使用节点或机架。 Juggernaut使用Redis进行持久化（更正：它使用Redis作为pub/sub），并且Faye仅在内存中保留状态。

1. 以上所有内容都准确吗？
2. 王菲说，它实现Bayeux - 我觉得剑圣并没有这样做 - 是因为剑圣是较低的水平（IE，我可以用贝叶剑圣实现）
3. 莫非王菲开关使用Socket.IO浏览器的JavaScript图书馆，如果它想？或者做他们的JavaScript库做根本不同的事情？
4. 项目之间是否存在任何其他建筑/设计/哲学差异？

Answer 1

披露：我是Faye的作者。

1. 关于王菲，你说的一切都是真的。
2. Faye实现了大部分的Bayeux，现在唯一缺少的是服务渠道，我还没有确信它的实用性。特别是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. 王菲刚刚发布/订阅，它只是基于一个稍微复杂的协议，有很多内置的乐事：
   • 服务器端和客户端扩展
   • 通配符模式匹配在通道路线
   • 自动重新连接，例如当WebSockets的死亡或服务器脱机
   • 客户端适用于所有的浏览器，在手机上，并在节点和Ruby

王菲可能看起来比剑圣很多更复杂的服务器端，因为剑圣代表更多，例如它将传输协商委托给Socket.IO并将消息路由委派给Redis。这些都是很好的决定，但我决定使用贝叶斯意味着我必须自己做更多的工作。至于设计理念，Faye的首要目标是它应该在任何地方都可以使用Web，并且应该是绝对平凡的。我的入门非常简单，但它的可扩展性意味着它可以以非常强大的方式进行定制，例如，您可以通过添加身份验证扩展将其变成服务器到客户端推送服务（即阻止任意客户端推送服务） 。

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

我希望这有帮助。

Answer 2

Faye当然可以。 上Socket.IO顶部的类似项目的另一个例子：

https://github.com/aaronblohowiak/Push-It

Answer 3

1. 据我所知，是的，其实除了剑圣仅使用Redis的为PubSub的，不持久。也意味着大多数语言的客户端库已经被写入（因为它只需要一个Redis适配器）。
2. 剑圣没有实现贝叶，而是有一个非常简单的定制JSON协议
3. 不知道，可能是
4. 剑圣很简单，并且设计成这样的。尽管我没有使用过Faye，但从文档看，它的功能比PubSub更多。构建在Socket.IO之上也有其优势，Juggernaut几乎支持所有浏览器，包括桌面和移动设备。

我会对Faye的作者的评论真正感兴趣。正如我所说，我没有使用它，并且知道它与Juggernaut相比会是多么的棒。这可能是使用最佳工具进行工作的情况。如果你需要的是pubsub，Juggernaut可以做得很好。