通过丢失连接 xmpp 丢失消息答案

【问题标题】：Losing messages over lost connection xmpp通过丢失连接 xmpp 丢失消息
【发布时间】：2014-02-28 17:40:59
【问题描述】：

我解决了这个问题

Lost messages over XMPP on device disconnected

但没有答案。

当由于某些网络问题导致连接丢失时，服务器无法识别它并继续向断开连接的接收器发送消息，这些消息永久丢失。

我有一个解决方法，我从服务器 ping 客户端，当客户端断开连接时，服务器能够在 10 秒后识别它并将更多消息保存在队列中，以防止它们丢失。

我的问题是可以通过使用我知道 psi 和许多其他 xmpp 客户端正在执行的其他方式来实现 100% 失败的保存消息传递。

在 ios 端我使用的是 xmppframework

【问题讨论】：

标签： ios iphone xmpp ejabberd xmppframework

【解决方案1】：

一种方法是在您的服务器上使用Advanced Message Processing (AMP)；另一种是在您的客户上使用Message Delivery Receipts。

前一个需要启用 AMP 的服务器实现并且发起客户端必须能够告诉服务器它想要什么样的传递状态报告（它想要 an error to be returned if the delivery is not possible）。请注意，这无论如何都不是万无一失的，因为在目标客户端失去与服务器的连接的那一刻和服务器机器上的 TCP 堆栈检测到这一点并告诉服务器的那一刻之间存在一个窗口：在此窗口期间，所有发送到客户端被服务器认为可以发送，因为在 TCP 层中没有消息边界的概念，因此如果服务器进程设法将消息节的 XML 填充到其 TCP 连接的系统缓冲区中，它认为该节发送——一旦 TCP 堆栈说连接丢失，它就无法知道它的流的哪些位没有到达接收器。

后一个是防弹的，因为客户端依赖于关于消息接收的明确通知。不过，这确实增加了健谈。作为回报，此功能不需要服务器支持 - 它仅在客户端中实现。

【讨论】：

由于这些重大限制，本协议不提供完全甚至部分的可靠性或保证交付。因此，发送方不应该对它没有收到确认消息这一事实赋予任何意义，除非它已经与接收方确认接收请求将被接受；但是，这样做的方法超出了本规范的范围，不建议在没有这些方法的情况下采取任何特定的操作（例如重新发送内容消息）。后者的摘录表明否则
我已经实现了这样的机制，如果丢失，消息将永远处于挂起状态。
来自客户端的Delevry ack和排队有争议的消息确保了消息的传递，但在基于房间的聊天的情况下，这种方法代价高昂..
如何确定我要发送的消息会丢失？
@AnandPrakash，你不能。我在回答中概述的方式是“主动的”——因为他们通过以一种或另一种方式将一些确认数据发送回原始客户端来主动确认消息的传递。

【解决方案2】：

使用 XEP-0198 并享受...

http://xmpp.org/extensions/xep-0198.html

【讨论】：

【解决方案3】：

对于我正在开发的 XMPP 客户端，使用了以下机制：

为项目添加 Reachability，以便在手机出现连接问题时快速检测到。
使用XEP-0198 的修改版本，添加服务器发送的确认。因此，客户端发送一条消息，服务器用回执确认。稍后，接收用户也将使用收据进行确认。对于您发送的每条消息，您都会收到两个确认，一个来自服务器，一个来自客户端。这当然需要在服务器上进行修改。
当应用未连接到 XMPP 服务器时，消息会排队。
当应用再次登录到 XMPP 服务器时，应用会获取所有未经服务器确认的消息并再次发送。

为此，您必须将消息以三种可能的状态本地存储在应用程序中：“未发送”、“服务器确认”、“用户确认”

【讨论】：

在没有使用 xep 0198 的情况下在客户端使用 ack 是否有一些服务器端解决方案？
它是由后端开发人员在内部编写的，尽管我知道这不是很多工作。基本上，每次您在服务器上收到“聊天”消息时，都会用另一条包含送达回执的消息回复它。从客户端看，它看起来像 XEP-0198
接收方未连接互联网，XMPP服务器认为他已连接，导致消息丢失，您是如何处理的？
@AnandPrakash 它不会导致消息丢失。在这种情况下，客户端不会向服务器发送 ACK。在 60 秒未收到 ACK 后，服务器将断开客户端（它认为这是一个错误的连接）。当客户端重新连接时，消息将再次传递。