我试图从ØMQ guide确定所谓'Extended Pub-Sub architecture'的确切行为和潜在局限性 .
描述了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上线之前订阅了，那么这是一个问题吗？是否可以从XSUB获知PUB预先存在的订阅？
我的系统将拥有具有动态生命周期的节点 . 这是一个问题，还有其他我应该注意的问题吗？
1 回答
不，那会自行解决 .
对，就是这样 .
您将丢失没有订阅者的已发布消息，因此要么创建Windows发布消息的代理，要么让订阅者要求发布者重新发布消息，并对消息进行幂等处理 .
Here's a sample您可以使用的全双工代理 . 你会注意到，如果你在"ping"（球的发布者）之前启动"pong"（球反弹的墙），它将全部工作，但是如果你在pong订阅者启动之前发布了ping，它将是丢失 .