nanomsg (nng) 中的多个发布者和订阅者
multiple publishers & subscribers in nanomsg (nng)
如何使用 TCP 传输设置多个发布者和订阅者。我怀疑您不会自动 mesh/bus 创建。所以每个发布者都需要一个唯一的 IP 绑定点，对吗？他们只是让订阅者连接到单个套接字上的每个发布者。
（讨论于：https://www.freelists.org/post/nanomsg/does-nanomsg-support-multi-producer-in-pubsub-mode,10）
基本正确吗？
我倾向于 pub/sub 而不是 bus/mesh 方法的原因是（我承认我很可能弄错了）-
- 我不需要全连接网格
- 我认为你在每个节点的基数树过滤比我想出的要好
- 我喜欢 pub/sub 的 "auto-discovery" 方面，而不是为总线传输手动连接网格
- （即自动 "entry and exit from mesh"）
基本上我有 2 个制作人（他们主要做发布，但偶尔会收到要求在发布的流上添加额外信息，所以他们确实需要倾听）
然后大约有五个消费者，他们主要从发布者那里接收数据流，但偶尔也需要向生产者发送请求。
是的，我希望发布是异步的，订阅的 recv() 也是如此（在我使用它的上下文中不允许阻塞）。
所以这是一个双向 pub/sub 架构。我正在寻找实现它的最简单方法。 （交通很畅通）。
当然，UDP 传输会很适合这个，但我不能屏住呼吸。
简单：
按照设计的方式使用 NN_PUB/NN_SUB，用于非阻塞、异步、广播方向。
使用另一个异步通道 "bottom-up"，无论是 NN_PAIR/NN_PAIR 还是任何其他更复杂的可扩展正式通信原型模式，例如 NN_PUSH/NN_PULL 或符合您的意图和延迟目标的反向 NN_PUB/NN_SUB。
工作进程将可以自由地 .nn_send() 只要其中一个感到有这样的需要，其余的就交给 "central" 进程。
考虑到缩放是 1:5 并且工作流很轻，正如您之前 post 编辑的那样，除了丢失的消息外，确实没有隐藏的陷阱（同样，主要解决方案是可靠的消息传递协议已经在较早的 post ).
中提出。
在 "central" 节点上，您只是定期 .nn_poll() 这些信令通道（再次以非阻塞异步方式）和 .nn_recv() 数据，以防万一，当这样的频道已经 POSACK'ed 一条消息已经存在，以便在您的应用程序代码端获取和处理时。
这就是你所需要的。
NanoMSG NNG 非常对称且正交。我与 gdamore 进行了几次讨论。
每个端点可以是 push、req、bus 或其他任何类型
您可以有多个端点（例如 2 个推送，或一个推送和 req/res）
协议可以在任一方向
Rec 可以是阻塞的、异步的或基于轮询的。
如果您想了解如何执行此操作，请参阅：
如何使用 TCP 传输设置多个发布者和订阅者。我怀疑您不会自动 mesh/bus 创建。所以每个发布者都需要一个唯一的 IP 绑定点，对吗？他们只是让订阅者连接到单个套接字上的每个发布者。
（讨论于：https://www.freelists.org/post/nanomsg/does-nanomsg-support-multi-producer-in-pubsub-mode,10）
基本正确吗？
我倾向于 pub/sub 而不是 bus/mesh 方法的原因是（我承认我很可能弄错了）-
- 我不需要全连接网格
- 我认为你在每个节点的基数树过滤比我想出的要好
- 我喜欢 pub/sub 的 "auto-discovery" 方面，而不是为总线传输手动连接网格
- （即自动 "entry and exit from mesh"）
基本上我有 2 个制作人（他们主要做发布，但偶尔会收到要求在发布的流上添加额外信息，所以他们确实需要倾听） 然后大约有五个消费者，他们主要从发布者那里接收数据流，但偶尔也需要向生产者发送请求。
是的，我希望发布是异步的，订阅的 recv() 也是如此（在我使用它的上下文中不允许阻塞）。
所以这是一个双向 pub/sub 架构。我正在寻找实现它的最简单方法。 （交通很畅通）。
当然，UDP 传输会很适合这个，但我不能屏住呼吸。
简单：
按照设计的方式使用 NN_PUB/NN_SUB，用于非阻塞、异步、广播方向。
使用另一个异步通道 "bottom-up"，无论是 NN_PAIR/NN_PAIR 还是任何其他更复杂的可扩展正式通信原型模式，例如 NN_PUSH/NN_PULL 或符合您的意图和延迟目标的反向 NN_PUB/NN_SUB。
工作进程将可以自由地 .nn_send() 只要其中一个感到有这样的需要，其余的就交给 "central" 进程。
考虑到缩放是 1:5 并且工作流很轻，正如您之前 post 编辑的那样，除了丢失的消息外，确实没有隐藏的陷阱（同样，主要解决方案是可靠的消息传递协议已经在较早的 post ).
中提出。在 "central" 节点上，您只是定期 .nn_poll() 这些信令通道（再次以非阻塞异步方式）和 .nn_recv() 数据，以防万一，当这样的频道已经 POSACK'ed 一条消息已经存在，以便在您的应用程序代码端获取和处理时。
这就是你所需要的。
NanoMSG NNG 非常对称且正交。我与 gdamore 进行了几次讨论。
每个端点可以是 push、req、bus 或其他任何类型 您可以有多个端点（例如 2 个推送，或一个推送和 req/res） 协议可以在任一方向 Rec 可以是阻塞的、异步的或基于轮询的。
如果您想了解如何执行此操作，请参阅：