11

我正在尝试做一个发布/订阅架构，其中多个发布者和多个订阅者存在于同一总线上。根据我在互联网上阅读的内容，只有一个套接字应该调用 bind()，而所有其他套接字（无论是 pub 还是 sub）都应该调用 connect()。

问题是，通过这种方法，我发现只有在套接字上实际调用 bind() 的发布者才会发布消息。我所有调用 connect() 的发布者似乎都默默地失败了，实际上并没有向总线发布任何消息。我已经确认这不是订阅者密钥问题，因为我编写了一个简单的“嗅探器”应用程序来订阅总线上的所有消息，并且它只显示调用 bind() 的发布者。

如果我尝试与发布者进行多次绑定，则 ipc 会发生静默窃取总线的“预期”zmq 行为，并且 tcp 会引发端口使用错误。

我已经用 ipc 和 tcp 端点验证了这种行为，但最终整个系统将使用 epgm。我假设（当然可能是错误的）在这种情况下我不需要代理，因为没有发生动态发现（端点是已知的，无论是 ipc、tcp 还是 epgm 多播）。

我是否缺少某些东西，也许是套接字设置，这会导致连接的发布者实际上没有发送他们的数据？根据我在互联网上看到的文献，我正在以“正确”的方式做事，但它仍然不起作用。

作为参考，我的发布者类具有以下设置端点的方法：

ZmqPublisher::ZmqPublisher()
: m_zmqContext(1), m_zmqSocket(m_zmqContext, ZMQ_PUB)
{}


void ZmqPublisher::bindEndpoint(std::string ep)
{
    m_zmqSocket.bind(ep.c_str());
}

void ZmqPublisher::connect(std::string ep)
{
    m_zmqSocket.connect(ep.c_str());
}

所以最终，我的问题是：在同一端点上处理多个发布者的正确方法是什么，为什么我看不到来自多个发布者的消息？

4

2 回答 2

4

它可能相关，也可能不相关，但0MQ 指南有以下略显神秘的评论：

理论上，对于 ØMQ 套接字，连接哪一端和绑定哪一端都没有关系。但是，在实践中存在未记录的差异，我稍后会谈到。现在，绑定 PUB 并连接 SUB，除非您的网络设计无法实现。

我还没有发现“稍后再来”实际发生在哪里，但我没有使用pub/sub太多，也没有详细阅读指南的“高级 Pub-Sub 模式”部分。

然而，对我来说，多个出版商在一个端点上的想法表明需要一个XPUB/XSUB风格经纪人。这不是关于动态发现，而是关于单点联系和路由。最终，我认为基于代理的拓扑会简化您的应用程序，并更容易识别问题。

于 2013-08-27T13:05:59.513 回答
3

您的错误是您使用 bind 调用单个发布者，而使用 connect 调用其他发布者。普通 PUB-SUB 模式不支持此功能。

ZeroMQ 中的普通 PUB-SUB 仅支持两种场景（见下图）：

  • 单个发布者，多个订阅者
  • 单个订阅者，多个发布者

在这两种情况下，“单”的一方必须bind和“多”的一方必须connect。否则，如果您想要多对多，您可以使用XPUB-XSUB或其他模式。

ZeroMQ / ZMQ / ØMQ Pub-Sub 模式。 两种场景：1）单个发布者，多个订阅者； 2) 单个订阅者，多个发布者
于 2021-05-29T14:19:12.523 回答