问在多用户聊天中向脱机用户发送消息(ejabberd)

EN

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

• 潜在的未绑定数量的参与者可能会在任何给定时间出现在房间中。

那么，究竟哪些用户当前不在MUC房间中，服务器应该将消息存储在脱机存储中？我的意思是，在一般情况下，服务器并不知道在它托管的给定房间中可能聊天的所有用户。

(好吧，如果这是唯一的问题，我必须承认，它可能适用于仅限成员的房间。)

• MUC房间不是“仅限本地服务器”：来自任何数量的其他服务器的潜在未绑定数量的用户可能会加入房间，并且将通过各自的服务器将消息传递给这些用户。

显然，这也是为什么"MUC房间离线存储“这种想法没有意义的另一个原因。根据定义，

• MUC房间是暂时的:当用户离线时，他们不在任何房间-(重新)连接一个房间是一种明确的行为。

这实际上是不支持离线存储的最重要原因。

如你所见，XMPP MUC房间很像IRC的类固醇聊天。

因此，您真正想要的是"room history"-a，它是XMPP-0045扩展的一部分，它允许客户端显式地向房间请求他们错过的消息历史记录。在某种意义上，代替为每个用户存储离线消息，聊天室可以被配置为仅存储发送给它的特定数量的最新消息(或在给定时间段内的所有此类消息)。则房间支持按加入用户查询这些消息。

您可以探索另一种可能性：XEP-0033的"multicast addressing" (“扩展节寻址”)。基本上，它允许客户端使用特殊的多播服务一次将其消息发送给多个接收者。好处是离线存储又出现了。缺点是，我怀疑ejabberd是否支持这种开箱即用的组播服务，而且似乎该扩展留下了许多细节，关于如何实现它没有具体说明。

当我试图为我的聊天应用实现群聊时，我面对了你的问题。我面临着同样的问题，即MUC没有为每个收件人存储离线消息。我不想检索MUC历史，这需要用户重新加入每个MUC来更新他的消息数据库。我想要的是让服务器按收件人保存离线消息，并让收件人在联机时获得所有MUC消息(而不必加入每个MUC)。

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

如果有什么不清楚的地方，请告诉我。

附加细节:本质上，当用户想要创建群聊时，我们的应用程序会创建一个pubsub节点和一个MUC。您需要熟悉这两个概念。对于pubsub节点，您需要设置一个选项以允许任何订阅者发布。当用户发送消息时，他实际上在节点上发布，ejabberd会将消息发送给所有订阅者，就像它是常规消息一样(除了它来自pubsub.yourdomain.com)。因此，如果收件人离线，ejabberd会将此消息存储为任何其他常规消息。

这不是ejabberd处理MUC消息的方式。这些只发送给当前在聊天室的人。然而，消息的历史可以由ejabberd存储，但是对于接收者来说，他需要加入MUC才能获得历史记录。这意味着每次应用程序重新连接时，它将不得不加入用户现有的所有MUC。我们发现这是不实际的。

我们也对相同的群聊使用MUC，但这只是为了存储参与者，以便用户可以在任何时候获得列表(不能使用pubsub)。

与MUC相比，使用pubsub的另一个好处是ejabberd存储pubsub数据的方式更加高效。我还没有深入研究过这一点，但我希望pubsub能提供更好的性能。

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

MUC的目标是尽可能多地依赖现有的MUC规范，同时做出尽可能小的更改，使移动组对话客户端变得容易。

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

以下是文档链接：https://docs.ejabberd.im/developer/proposed-extensions/muc-sub/

更多信息请点击此处：https://blog.process-one.net/xmpp-mobile-groupchat-introducing-muc-subscription/