如何使用 TCP 传输设置多个发布者和订阅者。我怀疑您没有自动创建网格/总线。因此，每个发布者都需要一个唯一的 IP 绑定点，对吧？他们只是让订阅者通过单个套接字连接到每个发布者。
（这在以下文章中进行了讨论：https://www.freelists.org/post/nanomsg/does-nanomsg-support-multi- Producer-in-pubsub-mode,10 https://www.freelists.org/post/nanomsg/does-nanomsg-support-multi-producer-in-pubsub-mode,10 )
这基本上是正确的吗？
我倾向于使用 pub/sub 而不是总线/网状方式的原因是因为（我承认我很可能是错误的）-
- 我不需要完全连接的网格
- 我认为你在每个节点的基数树过滤比我想出的要好
- 我喜欢 pub/sub 的“自动发现”方面，而不是总线传输的网格的手动接线
- （即自动“进入和退出网格”）
基本上我拥有的是 2 个生产者（主要进行发布，但偶尔会收到在正在发布的流上添加附加信息的请求，因此他们确实需要监听）
然后大约有五个消费者，他们主要接收来自发布者的数据流，但偶尔需要向生产者发送请求。
是的，我希望 pub 是异步的，以及订阅的 recv() （在我使用它的上下文中不允许阻塞）。
所以这是一个双向的发布/订阅架构。我正在寻找实现这一点的最简单方法。 （交通很顺畅）。
当然，UDP 传输对此会很好，但我并没有屏住呼吸。
Easy :
Use the NN_PUB/NN_SUB正如它的设计，用于非阻塞、异步、广播方向。
“自下而上”使用另一个异步通道，无论是NN_PAIR/NN_PAIR或任何其他更复杂的可扩展正式通信原型模式，例如NN_PUSH/NN_PULL或相反的NN_PUB/NN_SUB这既符合您的意图又符合您的延迟目标。
工作进程将可以自由地.nn_send()每当其中一个人感到有这样的需要时，其余的事情就掌握在“中央”进程的手中。
鉴于缩放比例为 1:5 并且工作流程很轻，正如您之前发布的那样，除了丢失的消息之外，确实没有隐藏的陷阱（同样，在之前的文章中已经提出了可靠消息传递协议的主要解决方案）。
在“中央”节点上，您只需.nn_poll()这些信号通道定期（同样，以非阻塞异步方式）并且.nn_recv()数据只是在这种情况下，当这样的通道已 POSACK 处理一条消息时，该消息已经存在在那里，以便在您的应用程序代码端获取和处理。
这就是你所需要的。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
