如何在Q ++中将扩展PUB-SUB模式中的发布者和订阅者与ZeroMQ中的中介同步？

Question

Extended PUB/SUB topology

我在一个具有1个中介的用例中有多个发布者和多个订阅者。

在ZeroMQ指南中，我了解了如何使用其他 REQ/REP 套接字同步1个发布者和1个订阅者。我尝试为我的用例编写同步代码，但如果我尝试根据1-1 PUB/SUB给出的逻辑编写代码，那就太乱了。

我们只有1位发布商时的发布商代码是：

//Socket to receive sync request
zmq::socket_t syncservice (context, ZMQ_REP);
syncservice.bind("tcp://*:5562");

//  Get synchronization from subscribers
int subscribers = 0;
while (subscribers < SUBSCRIBERS_EXPECTED) {

    //  - wait for synchronization request
    s_recv (syncservice);

    //  - send synchronization reply
    s_send (syncservice, "");

    subscribers++;
}

当我们只有1个订户时，订户代码是：

zmq::socket_t syncclient (context, ZMQ_REQ);
syncclient.connect("tcp://localhost:5562");

//  - send a synchronization request
s_send (syncclient, "");

//  - wait for synchronization reply
s_recv (syncclient);

现在，当我有多个订阅者时，每个订阅者是否需要向每个发布者发送请求？

我的用例中的发布者来去匆匆。他们的号码不固定。

因此，订阅者将无法了解要连接的节点数量以及存在或不存在的发布者。

请建议一个逻辑来同步扩展的 PUB/SUB 代码

Answer 1

鉴于 XPUB/XSUB 介体节点存在，

实际的 PUB -node发现对于 XSUB -mediator-side来说可能完全不费力（实际上主要是避免这样做）。

只需使用反转 XSUB.bind() - s / PUB.connect() - s，问题就不复存在了。

聪明，不是吗？

PUB - 节点可能来去，但 XSUB Policy-mediator节点的一侧无需费心（除了少量初始.setsockopt( { LINGER, IMMEDIATE, CONFLATE, RCVHWM, MAXSIZE } )性能调整和健壮性增加设置），享受实际主题过滤器仍然有效且有效的组合 { {1}} 设置在服务中并且可以集中维护此类组合主要与现在/稍后的.setsockopt( zmq.SUBSCRIBE, ** ) - 生活/功能障碍的半时态组的状态/动态保持不可知关系 .connect() -side Agent-nodes。

更好的是，不是吗？