Question

但我不需要真正的多播IP（例如239.0.0.0:3000）我的负载非常轻。所以我不关心背压。

是的，我可以使用总线范例。但是说我想先用pubsub进行测试。

发件人使用什么作为发送到url的tcp发送给多个客户端？

（我实际上正在使用下一代nanomsg）：

我可以发送给 TCP：// *：3000

我可以将订阅者绑定到该地址吗？

Answer 1

我可以发送给 tcp://*:3000 吗？

是的

我可以将订阅者绑定到该地址吗？

是的。当然，一个人必须拥有自己的集合（显然不能“共享”任何专有资源）
但是
PUB 将必须通过正确配置的.connect()-s（nng_dial()-s来“编织”，以便到达所有远程AccessPoint-s，它不需要自己知道。

对于ZeroMQ和nanomsg，自由使用反向.bind()/.connect()是常见的做法，但请检查nng是否保留了这种选择自由。

...想要首先使用pubsub进行测试。 这将是什么，发件人将其用作发送给tcp的url的URL，以发送给多个客户端吗？

好吧，如果只是从ZeroMQ / nanomsg / nng开始，情况似乎有些混乱。

第一：
最初的zeromq API v2.x和 nng 都将不发送给仅多个客户端，但是将始终发送给所有客户端对Socket原型引擎可见（可能的配置调整细节不在本文范围之内）。

换句话说， PUB 端的应用程序代码根本不会决定谁会收到消息。曾经所有见过的客户都在“交付清单”上，并且网络将必须将所有副本传递给所有能够进行临时连接的此类客户（有些很快，有些稍后，而这些其他客户永远都看不到）是一个单独的演唱会-也不是您的问题，如您先前的问题所述）。

PUB/SUB 订阅机制是此处的重要问题。 nng和早期zeromq v2.x都执行了TOPIC过滤的订阅，该订阅实际上是在每条消息传递到远程客户端后才进行的，但代价是{PASS | FAIL}-拒绝，基于该远程客户端订阅的主题。因此，所有消息都是根据设计流向所有客户端的。

这意味着，对于这种类型的本地（仅）网络_{（如上一个问题中所述），您的网络级通信多播实际上没有任何好处。} {{1} }可扩展的正式沟通模式原型。另外，nng尚未发布支持这种传输类的实现（而zeromq则提供了支持）。

下一个：
似乎，简短阅读[ ZeroMQ hierarchy in less than a five seconds ]部分中的主要概念差异可能有助于消除术语和乐高风格基础设施设置的概念：

代码显然是示意性的，不完整的，但易于阅读和理解：

PUB/SUB

Answer 2

我从gdamore获得的信息似乎表明不能使用tcp：// *：3000，因为您需要将生产者/发布者绑定到某个接口。但是，我现在有一个固定的终结点，即在发布服务器上有1-1个发布服务器到订阅服务器。

现在，我发现组播实际上是不可能的（直到允许UDP传输），我修改了问题，并将其放在最终解决方案的上下文中。参见：