我正在开发一个使用XMPP协议的移动应用程序聊天，成功实现一对一聊天后，现在处于多用户聊天（MUC）阶段，因为有三种不同的MUC实现方法可用传统MUC ， Muclight ， MUC Sub ，现在很多问题
除此之外还有其他方法吗？
哪种方法最好实施？
不同方法的优点和缺点是什么？
哪种方法最先进？
哪种方法问题少？
哪个最可靠？
答案 0 :(得分：3)
免责声明：我为Erlang Solutions工作，开发MongooseIM，因此开发MUC Light。
我会尝试逐点解决你的问题：
除此之外还有其他方法吗？
有MIX，一种新的（与传统的MUC相比）基于PubSub的XMPP群组通信/信令解决方案。我不知道任何公开可用的实现，但在XSF中似乎有一些共识，使其成为传统MUC的官方继承者。
从实现者的角度来看，PubSub可能是所有XEP中最长和最复杂的（XEP是XMPP扩展协议，或者只是说其他XMPP功能）。 MIX建立在PubSub之上，它增加了另一层。我没有使用MIX的实践经验，但从相关规范的数量来猜测，这不是最简单的入门解决方案。
同时，PubSub（因此MIX）是移动友好的，即用户体验不会因频繁的连接中断而降级，不依赖于状态更新，易于存档，因此多设备同步可能非常容易
哪种方法最先进？哪种方法问题较少？不同方法的利弊是什么？
Traditional MUC定义了用户可以在一个房间（访问者，参与者，主持人），特权（用户可以做什么和不能做什么）和从属关系（用户可以加入某个房间）的丰富角色集？他/她是主人？被踢/被禁止？）。它基于传统的IRC频道结构，但标准化了这一概念。该模型相当丰富，但同时可能有点过于复杂。传统MUC严重依赖于客户端与服务器的持续连接 - 断开连接需要客户端应用程序显式重新加入它所在的任何房间。没有标准方法来告知用户所属的房间，所以此信息必须存储在app / device中。
我不确定传统的MUC与MIX在房间/订阅模式方面的比较。
根据官方文档判断，MUC/Sub是对传统MUC的扩展，保留了所有原始功能并添加了类似PubSub的订阅消息选项，而不依赖于状态交换和与服务器的持续连接。其他（大多数？全部？）交互也是可能的，而交换存在节的必要性被取消。据我所知，它只在ejabberd中实现。
MUC Light（不要错过developer's guide以获取更多详细信息）采用不同的方法为移动设备启用群组通信。它简化了传统的MUC角色/联盟模式（可能是好的或坏的，取决于您的要求），不需要与服务器和状态交换的连续连接来加入/离开房间（这绝对是有益的）移动设备）并附带传统的MUC协议兼容层（尽管它还引入了一个新的，更简单的协议层）。实施方面，MUC Light房间应该比MongooseIM中的传统MUC房间更好地扩展，并且由于它们的设计更具容错性。
哪种方法最好实施？
让我们从可用的实现开始：
总而言之，实施“最佳”取决于您的要求。如果您熟悉PubSub并将其用于其他情况，那么MIX可能是最佳选择（如果可以找到/开发适当的服务器范围实现）。如果你需要丰富的聊天室模型和功能集，传统的MUC将会发挥作用，但是让它在移动设备上运行会感觉很笨拙。 MUC / Sub可能会减轻这种感觉，但我不知道客户端lib的可用性。 MUC Light非常简单，但在某些方面可能有所限制 罕见的情况。不过，这可能是最容易开始合作的。
答案 1 :(得分：0)
对于简单的群聊，你可以从Extended Stanza Addressing开始 - 它在openfire（开箱即用），ejabberd（mod_multicast）和韵律（mod_addressing）中得到支持。使用扩展节点寻址，您可以像在电子邮件中一样为邮件添加多个收件人。