0

我正在开发一个使用 XMPP 协议的移动应用程序聊天，在成功实现一对一聊天之后，现在处于多用户聊天 (MUC) 阶段，由于有三种不同的 MUC 实现方法可用传统 MUC、Muclight、MUC Sub , 现在有很多问题

除了这个还有什么办法吗？

哪种方法最好实施？

不同方法的优缺点是什么？

哪种方法是最先进的？

哪种方法问题较少？

哪个最可靠？

4

2 回答 2

4

免责声明：我为开发 MongooseIM 和 MUC Light 的 Erlang Solutions 工作。

我将尝试逐点解决您的问题：

除了这个还有什么办法吗？

MIX是一种新的（与传统的 MUC 相比）基于PubSub的 XMPP 组通信/信令解决方案。我不知道有任何公开可用的实现，但 XSF 似乎达成了一些共识，使其成为传统 MUC 的正式继承者。

从实现者的角度来看，PubSub 可能是所有 XEP 中最长和最复杂的（XEP 是 XMPP 扩展协议，或者简单地说是附加的 XMPP 功能）。MIX 建立在 PubSub 之上，它又增加了一层。我没有使用 MIX 的实践经验，但从相关规范的数量猜测，这并不是最容易上手的解决方案。

同时，PubSub（因此是 MIX）对移动设备友好，即用户体验不会因频繁的连接中断而降低，不依赖状态更新，易于存档，因此多设备同步可能非常容易。

哪种方法是最先进的？哪种方法问题较少？不同方法的优缺点是什么？

传统的 MUC定义了用户在房间中可以扮演的一组丰富的角色（访客、参与者、主持人）、权限（用户可以做什么和不能做什么）和从属关系（用户可以加入某个房间吗？他/她是所有者？被踢/被禁止？）。它基于 IRC 频道的常规结构，但将概念标准化。该模型非常丰富，但同时可能有点过于复杂。传统的 MUC 严重依赖于客户端与服务器的持续连接 - 断开连接需要客户端应用程序显式重新加入它所在的任何房间。没有标准的方法来告诉用户是哪些房间的成员，所以这些信息必须存储在应用程序/设备中。

我不确定在房间/订阅模型方面传统 MUC 与 MIX 相比如何。

从官方文档来看，MUC/Sub是对传统 MUC 的扩展，保留了所有原始功能，并添加了类似 PubSub 的消息订阅选项，无需依赖状态交换和与服务器的持续连接。其他（大多数？全部？）交互也是可能的，同时交换存在节的必要性被取消。据我所知，它只在 ejabberd 中实现。

MUC Light（不要错过开发者指南了解一些额外的细节）采用不同的方法来启用移动设备的群组通信。它简化了传统的 MUC 角色/从属关系模型（这可能是好事也可能是坏事，取决于您的要求），不需要与服务器的持续连接和状态交换来加入/离开房间（这绝对有利于移动设备）并带有传统的 MUC 协议兼容层（尽管它还引入了一个新的、更简单的协议层）。在实施方面，MUC Light 房间应该比 MongooseIM 中的传统 MUC 房间更好地扩展，并且由于它们的设计更具容错性。

哪些方法最好实施？

让我们从可用的实现开始：

  • 我不知道服务器端或客户端是否有任何可用的 MIX 实现
  • MUC/Sub是ejabberd扩展，不知道有没有客户端库支持，不是官方的XEP
  • 传统的 MUC 在客户端库和服务器端软件中都可以广泛使用
  • 坦率地说，MUC Light 是 MongooseIM 扩展，不是官方 XEP，但在 XMPPFramework (iOS) 和 Smack (Android) 中有客户端支持

总而言之，什么是“最佳”实施取决于您的要求。如果您熟悉 PubSub 并将其用于其他情况，则 MIX 可能是要走的路（如果可以找到/开发合适的服务器范围的实现）。如果您需要丰富的聊天室模型和功能集，传统的 MUC 就可以完成这项工作，但让它在移动设备上运行会感觉很笨拙。MUC/Sub 可能会减轻这种感觉，但我不知道客户端库的可用性。MUC Light 非常简单，但在极少数情况下可能会受到限制。尽管如此，它可能是最容易开始使用的。

于 2017-08-07T09:36:15.057 回答
0

对于简单的群聊，您可以从Extended Stanza Addressing开始- openfire（开箱即用）、ejabberd（mod_multicast）和 prosody（mod_addressing）都支持它。使用扩展的节寻址，您可以像在电子邮件中一样将多个收件人添加到您的消息中。

于 2017-08-07T14:23:22.603 回答