流管理中的死连接消息和交付收据接收延迟 - MongooseIM 服务器 2.0.0答案

【问题标题】：Dead connection message and delivery receipt received delay in stream management - MongooseIM server 2.0.0流管理中的死连接消息和交付收据接收延迟 - MongooseIM 服务器 2.0.0
【发布时间】：2018-05-14 06:49:27
【问题描述】：

我在客户端或服务器端都启用了流管理。我有两个用户 A 和 B。两个用户都在线。然后用户 A 突然失去连接。但是 A 用户仍然在线出现在用户 B 和服务器上。在此期间，用户 B 在用户 A 上发送消息。这些消息不会丢失，但是当用户 A 再次出现在线时，它将在 2-3 分钟后收到这些消息。我将在离线存储和交付收据上收到消息节在 SM 存储上。此问题同样发生在一对一聊天和 mucLight 上。我需要定制任何 mongooseIM 模块吗？请指导我为什么用户在失去连接时收到延迟消息。是否可以将 SM 存储更改为离线存储 (MAM)。这是相同问题的链接我在此链接 (https://www.ejabberd.im/faq/tcp) 上发现了相同的问题，但没有丢失我的消息，只是收到延迟。

我在我的 Android 应用上使用smack-4.2 lib。下面的代码用于在XMPPTCPConnection 中启用流管理。

  static{
        XMPPTCPConnection.setUseStreamManagementDefault(true);
        XMPPTCPConnection.setUseStreamManagementResumptionDefault(true);
   }

这是我的 ejabbered.cfg 文件，用于 mod_stream_management 模块

      {mod_stream_management, [
                       % default 100
                       % size of a buffer of unacked messages
                       % {buffer_max, 100}

                       % default 1 - server sends the ack request after each stanza
                       % {ack_freq, 1}

                       % default: 600 seconds
                       % {resume_timeout, 600}
                      ]},

我还在我的配置文件中启用了以下模块

   %% Only archives for c2c messages, good performance.
  {mod_mam_odbc_user, [pm]},
  {mod_mam_cache_user, [pm]},
% {mod_mam_mnesia_dirty_prefs, [pm]},
% {mod_mam_odbc_arch, [pm, no_writer]},
  {mod_mam_odbc_async_pool_writer, [pm]},
  {mod_mam, []}

我在这里 smack connect to xmpp server with previous stream id 找到了很少的解决方案，但它不适用于 mongooseIM-2.0 服务器。

先谢谢你了。

【问题讨论】：

标签： android xmpp smack mongoose-im stream-management

【解决方案1】：

我假设用户 A 在重新连接时没有使用流恢复（由 XEP-0198: Stream Management 定义）而只是开始一个新会话。这意味着在服务器端仍有一个悬空进程等待流恢复发生。当用户 A 已经重新连接到服务器时，悬空进程超时（需要 resume_timeout 秒）并将其存储的消息发送到传出消息缓冲区中以进行传递。

如果您不喜欢这种行为，您可以执行以下操作之一：

a)（不建议）禁用 Stream Management 并发送 Message Archive Management 查询（即使用 mod_mam）以在每次与服务器建立新连接时获得最新的对话状态

b) 启用流管理，但尽可能使用流恢复；也就是说，你总是尝试恢复之前的会话，除非你没有之前的会话 ID 或者服务器拒绝了恢复请求；理想情况下，您还可以使用消息存档管理

c) 使用Delayed Delivery aka mod_offline，但在极少数情况下，如果您使用多个设备，则可能会将消息发送到错误的设备；例如，如果您有手机和笔记本电脑，您的消息可能会到达笔记本电脑，但永远不会到达手机

【讨论】：

@erszcv 感谢您的重播。在您的以上 3 个条件中，我已经尝试过。 a) 如果流管理被禁用，则客户端无法接收addStanzaIdAcknowledgedListener。所以我不能这样做。 b) 我已经尝试过只启用流恢复。它工作正常，但所有以前的会话消息都来晚了。我的 mongooseIM 服务器上也启用了消息存档管理。 c) 死连接消息未存储在mod_offline。
我不知道 Smack，但确认是 Stream Management 的一部分 - 如果您不想要 Stream Management，请不要使用 addStanzaIdAcknowledgedListener。在情况 b) 中，您总是会尝试使用 XEP-198: Resumption 中描述的 Stream Resumption 协议来恢复 - 您必须弄清楚 Smack 如何实现这部分并找到正确的 API：如果成功，您将立即收到消息，如果失败，您将不得不查询存档并且可能会延迟收到它们。
是否存在流冲突问题？表示为已打开连接的资源打开了新用户连接。所以服务器发送旧的流连接来关闭它，因为有一个新的资源连接处于活动状态。

【解决方案2】：

您是否尝试过使用mod_ping 并在ejabbered.cfg 文件上进行配置。

{mod_ping, [{send_pings, true}]},

更多详情请点击此链接mod_ping

【讨论】：

如果启用了流管理，PingManager 在 smack lib 中不起作用。相同的配置在ejabberd 服务器上完美工作，但在MongooseIM 服务器上不工作。