ZMQ在使用epgm进行PUB/SUB时，是否提供可靠性保证？

Question

我有一个应用程序将消息发送到一个或多个epgm SUB套接字的epgm PUB套接字。虽然大部分工作都正常，但如果订阅应用程序运行时间足够长，它通常会错过一条或几条消息。（我的消息有序列号，所以我可以知道是否有丢失或顺序错误的消息。）根据我对ZMQ文档的阅读，我原以为epgm的“可靠组播”特性会防止这种情况发生，即在SUB套接字收到一条消息后，保证它会继续收到消息，直到关闭或出现严重网络问题（例如，连接达到最大值）。

无论如何，这就是环境背景，但问题很简单：ZMQ对于epgm上的PUB/SUB提供了哪些可靠性保证（如果有的话）？

- scott

---

您是否在发布者中设置了高水印？ - Steve-o

仅使用默认设置。消息速率不高，每秒2个10B-160KB的消息，每个消息都在一个帧中。 （平均消息大小为80 KB。）认为1000已经足够了。 - scott

你是否验证了反向通道的正常运行：发送方和接收方是否使用正确的网络接口？例如，你可以在 WireShark 中遵循 PGM 协议。 - Steve-o

我还没有验证后端通道，不太清楚该怎么做。但我会看看明天能否弄清楚。我肯定在客户端和服务器上都使用以下格式设置网络接口：epgm://[本地接口的IP];[多播组IP]：[多播端口]，如果这与你所说的有关的话。 - scott

Answer 1

在ZeroMQ中，PGM实现使用一个内存窗口进行恢复，因此只有短暂的生命周期。如果由于发布速度快于恢复过渡而恢复失败，例如窗口耗尽，则底层的PGM套接字将重置并继续以最佳努力。

这意味着在高数据速率或严重的数据包丢失情况下，传输将不断重置，并且您将会丢失无法恢复的消息：因此无法保证可靠传送。

PGM配置针对实时广播，以使慢速接收器无法阻止发送方。该协议支持两种范式，但由于缺乏需求，后者未实现。

- Steve-o

---

恢复窗口的实际限制是什么？我将ZMQ_RECOVERY_IVL设置为10秒，在我的数据速率下，这是一个合理的内存量（<5MB），我从未观察到一次跳过超过2-3秒的数据。在这种情况下，我本以为我会得到可靠性。 - scott

看起来有些不对劲，请尝试启用OpenPGM日志记录，看看是否会出现任何有趣的信息。 - Steve-o

OpenPGM的日志提供了很多信息，但对我来说毫无意义。但是我将ZMQ_RECOVERY_IVL增加到100秒，将ZMQ_SNDBUF和ZMQ_RCVBUF增加到10 MB，这导致可靠性显著提高。 - scott

Answer 2

ZeroMQ仅有一个保证：所有的消息都是完整的，您永远不会收到部分消息。 它不保证可靠性。 您应该查看高水位线（HWM）行为的文档，这是丢弃消息的最常见原因，正如自杀蜗牛所示。

- minrk

---

EPGM不是“可靠组播”吗？如果它实际上并不能提供可靠性，为什么还要通过ZMQ提供该协议呢？为什么不直接通过原始UDP套接字支持组播呢？ - scott

@scott PGM 还实现了有序传递，交换网络将重新排序数据包，而 PGM 可以重新组装原始序列。此外，多播路径定义的重要语义也需要支持架构。 - Steve-o