具有ZeroMQ的单个端口上的双向REQ / REP

Question

我正在努力解决以下问题：

我想使用ZeroMQ在N个客户端和1个服务器之间进行双向异步请求/答复。

这意味着任何客户端都可以向服务器发出请求，并且服务器必须回复客户端。

以另一种方式，服务器必须能够向任何已标识的客户端发出请求，并且客户端必须答复服务器。

我认为我必须使用路由器/经销商，但是我不确定我是否同时需要它们。

此外，有没有办法仅使用服务器端和每个客户端上的一个端口来拥有整个范式？

Answer 1

  

问：有没有办法仅使用服务器/客户端的一个端口？

嗯，这是比较简单的部分。不可以。这是无法实现的。在大学里只有一个电话亭会在走廊上响起，但无助于打给各个部门的电话，正确地到达呼叫方的量子力学教授（而不是美术专业的教授）的电话就越少

仅使用一个端口就意味着有机会公开一个和唯一的一个ZeroMQ可扩展形式通信模式原型 AccessPoint 和（非常具体的PAIR/PAIR分布式行为原型）互连代理的 AccessPoint -s总是存在某种硬连线的分布式行为。

这意味着，使用一个端口只能提供一种且只有一种这样的分布式行为，而不是'em'的混合。

这也回答了您的第一部分。如果在从客户端节点到服务器的方向上使用了REQ/REP分布式行为原型，并且在从服务器到客户端节点的相反方向上使用了另一个REQ/REP分布式行为原型，则这些（定向）服务不能在同一address:port上共存。

  

奖励部分：一种拯救生命，但有点恶作剧的技巧
（不适用于医疗和/或急诊系统）

可以对REQ/REP消息传递方向中的一个和仅一个进行超采样，并添加一个棘手的“准协议”，以便为两个预期的信令方向提供相同的信道。如果从一侧发送足够多的协议消息，则为{client |服务器{} {1}}消息发起者将简单地发送NOP消息，足以使REQ/REP端答复方在静止时“准发起”其“准REP消息”是单一REQ分布式行为原型中的真实REP-AccessPoint。
是，性能和资源是这样做需要一定的成本，但是如果您的需求非常依赖使用一个端口，并且您的意识和部署生态系统可以忍受此类流量的增加，那么仔细的实时系统设计实践将有助于完成这项工作。超采样的REQ/REP数据流

您可能还喜欢在StackOverflow上的帖子，其中介绍了不可避免的相互死锁，分布式REQ/REP FSA-s会掉进去。

ZeroMQ hierarchy explained in less than a five seconds

UN-AVOIDABLE DEADLOCKS