Xmpp 在多用户聊天（ejabberd）中向脱机用户发送消息

实际上，我们正在使用ejabberd服务器作为客户端的一个聊天应用程序。除了集体聊天，一切都很顺利

我们使用MUC进行群聊，但它不会在用户离线时向其发送消息。有没有其他的插件或者什么东西可以让它工作

或者任何人都可以建议如何从群组聊天历史记录中接收该用户的脱机消息

---

提前感谢

这是因为多用户聊天室没有这样的概念。事实上，如果你再仔细想想，你就会明白为什么：

• 在任何给定的时间，一个房间中可能会出现数量可能不受限制的参与者
  那么，服务器应该将消息存储在脱机存储器中，具体针对哪些当前不在MUC室中的用户？我的意思是，在一般情况下，服务器并不知道所有可能在其托管的给定房间中聊天的用户
  （好吧，如果这是唯一的问题，我必须承认，它可能适用于仅限成员的房间。）

• MUC会议室不是“仅本地服务器”：来自任何数量的其他服务器的潜在未绑定用户可能会加入会议室，通过各自的服务器路由这些用户，将向这些用户发送消息
  显然，这是“多房间离线存储”这种想法毫无意义的另一个原因

• MUC房间从定义上来说是暂时的：当用户离线时，他们不在任何房间内（重新）进入房间是一个明确的动作
  事实上，这是不支持脱机存储的最重要原因

正如您所看到的，XMPP MUC聊天室非常类似于使用类固醇的IRC聊天室

因此，您真正想要的是

XMPP-0045

扩展的一部分，它允许客户端明确地向房间询问他们错过的消息历史记录。从某种意义上说，可以将文件室配置为只存储发送给它的特定数量的最新消息（或给定时间段内的所有此类消息），而不是为每个用户存储脱机消息。然后，聊天室支持由加入的用户查询这些消息

---

您还可以探索另一种可能性：

XEP-0033

（“扩展节寻址”）。基本上，它允许客户端使用特殊的多播服务一次将消息发送给多个收件人。好处是离线存储又出现了。不利的一面是，我怀疑ejabberd中是否支持这种开箱即用的多播服务，而且该扩展似乎留下了许多关于如何实现它的细节未明。

当我试图为我的聊天应用程序实现GroupChat时，我遇到了你的问题。我面临着同样的问题，MUC没有为每个收件人存储脱机邮件。我不想检索MUC历史记录，这需要用户重新加入每个MUC来更新他的消息数据库。我想要的是服务器按收件人保存脱机消息，并且收件人在联机时获取所有MUC消息（无需加入每个MUC）

我是通过pubsub做的。使用pubsub将强制服务器存储每个收件人的脱机邮件。当用户重新连接时，他将获得所有脱机消息，包括作为普通消息发送的pubsub消息——就是这样。不过，我和pubsub在MUC问题上遇到的一个问题是，很难获得订阅者名单。因此，当我的应用程序创建一个groupchat时，它会为消息创建一个pubsub节点，邀请所有参与者（包括自己）订阅pubsub，我的应用程序还会创建一个MUC，并使每个参与者都成为该MUC的所有者。这样，可以通过检查MUC的所有者列表来检索groupchat参与者的列表。MUC的唯一目的是保存参与者列表以及groupchat的名称。其他一切都由pubsub节点处理

有什么不清楚的请告诉我

其他详情： 基本上，当用户想要创建一个群组聊天时，我们的应用程序会创建一个pubsub节点和一个MUC。您需要熟悉这两个概念。对于pubsub节点，您需要设置一个允许任何订阅者发布的选项。当用户发送消息时，他实际上是在节点上发布的，ejabberd会将消息发送给所有订阅者，就像发送普通消息一样（来自pubsub.yourdomain.com的消息除外）。因此，如果收件人处于脱机状态，ejabberd会将此邮件存储为任何其他常规邮件

这不是ejabberd处理MUC消息的方式。这些信息只发送给聊天室里的人。但是，ejabberd可以存储消息的历史记录，但是收件人要获得历史记录，需要加入MUC。这意味着每次应用程序重新连接时，它都必须加入用户现有的所有MUC。我们发现这是不实际的

我们也对同一个groupchat使用MUC，但这只是为了存储参与者，以便用户可以随时获取列表（无法使用pubsub）

---

相对于MUC使用pubsub的另一个好处是ejabberd存储pubsub数据的方式更加高效。我还没有对此进行深入研究，但我希望pubsub的性能会更好。

16.09版本的新ejabberd服务器对多用户聊天有改进-MUC Sub：

MUC Sub的目标是尽可能多地依赖现有的MUC规范，同时进行尽可能小的更改，使移动组会话客户端变得简单

默认情况下，该功能处于启用状态。要使用它，只需确保在要使用它的房间中设置了新参数“Allow subscription”

以下是文档的链接：

---

这里有更多信息：

@EelLee，事实上，对于那些相当精通XMPP规范及其扩展的人来说，这个问题并不含糊；-）可能重复的