ZeroMQ PUB/XPUB/XSUB/SUB 过滤

Question

我正在尝试从ØMQ guide 中确定所谓的“扩展 Pub-Sub 架构”的确切行为和潜在限制。

XPUB 和 XSUB 的描述：

我们需要 XPUB 和 XSUB 套接字，因为 ZeroMQ 将订阅从订阅者转发到发布者。 XSUB 和 XPUB 与 SUB 和 PUB 完全相同，只是它们将订阅公开为特殊消息。代理必须将这些订阅消息从订阅者端转发到发布者端，方法是从 XSUB 套接字读取它们并将它们写入 XPUB 套接字。这是 XSUB 和 XPUB 的主要用例。

我已将 XSUB 和 XPUB 套接字设置为代理的 前端 和 后端，并将另一对 PAIR 套接字连接到捕获端口。这让我可以观察到通过代理传递的消息。

在我的架构中，每个节点都是 PUB 和 SUB。本质上，我希望这个 XPUB/XSUB 代理能够提供一个共享总线，带有主题前缀订阅。

SUB 节点连接后，它必须订阅一个（可能为空的）主题。这会导致通过代理传输一帧消息。假设我的主题是{0xff 0xFF}，消息是：

{0x01 0xFF 0xFF}

前导0x01 表示订阅，后跟主题字节。带有0x00 而不是0x01 的类似消息表示取消订阅。

我关心的是订阅信息在此架构中的确切保存位置。

根据指南：

从 ZeroMQ v3.x 开始，当使用连接协议（tcp:// 或 ipc://）时，过滤发生在发布者端。

如果过滤确实是在发布者端进行的，那么如果 SUB 在 PUB 上线之前 订阅会不会有问题？ PUB 是否会被告知预先存在的订阅，可能来自 XSUB？

我的系统将拥有具有动态生命周期的节点。这会是一个问题吗？还有其他我应该注意的问题吗？

Answer 1

如果过滤确实是在发布者端进行，那么在 PUB 上线之前 SUB 订阅会不会有问题？

不，这会自己解决的。

是否会通知 PUB 预先存在的订阅，可能来自 XSUB？

没错。

我的系统将拥有具有动态生命周期的节点。这会是一个问题吗？还有其他我应该注意的问题吗？

您将丢失没有订阅者的已发布消息，因此要么创建一个代理窗口发布消息，要么让订阅者要求发布者重新发布并对消息进行幂等处理。

Here's a sample 的全双工代理，您可以使用它。您会注意到，如果您在“ping”（球的发布者）之前启动“pong”（球反弹的墙），一切都会奏效，但是如果您在 pong 订阅者启动之前发布 ping ，它将丢失。