是否可以通过路由到物理地址来更改 ZMQ 消息流？答案

【问题标题】：Is it possible to change a flow of ZMQ messages with routing to a physical address?是否可以通过路由到物理地址来更改 ZMQ 消息流？
【发布时间】：2014-10-24 07:23:25
【问题描述】：

我可能会误解这一点，但似乎在 zmq 中使用 ROUTER/DEALER 模式时，当响应者收到请求时，它必须原路返回。

让回复者直接响应远程请求者似乎会减少网络延迟。

有没有办法做到这一点，也许通过传递物理地址而不是id？

有可能创建这样的系统吗？

我想看看像这样的传输链REQ->ROUTER->DEALER-> REP->REQ，其中REQ的两次出现代表同一台机器

【问题讨论】：

标签： networking asynchronous routing zeromq server

【解决方案1】：

您可以在这里做您正在寻找的事情，至少在某种程度上......但不要过度滥用系统以使其以非预期的方式运行，或者您会给自己制造一场维护噩梦。在这种情况下，“too far” 所在的行会因开发团队和项目而异，但请记住这一点。

以下是您提出的模式会遇到问题的几个原因：

您的 DEALER 套接字与其他两个套接字对等。 DEALER 套接字以循环方式发送数据，因此它将向您的 REP 套接字发送一条消息，而下一条将返回您的 ROUTER 套接字。可能不是你想要的。
没有明确的服务器套接字（您将bind() 打开）或客户端套接字（您将connect() 打开）。在您提出的模式中，它之所以有效，是因为套接字的总数是偶数，但如果您要在链中添加或删除一个套接字，您会遇到以下情况：

SOCKET A  ->  SOCKET B  ->  SOCKET C  ->  (SOCKET A)
CLIENT        SERVER        CLIENT        ( CLIENT )
CONNECT       BIND          CONNECT       ( CONNECT)

connect()s 的套接字无法连接到 connect()s 的另一个套接字。与bind() 的两个套接字相同。

您正试图打破这样的观念，即 REQ 套接字期望从它发送请求的套接字得到答复，而 REP 套接字对向它发送请求的套接字作出答复。如果这是可能的（我还没有调查过），那将是 my 的“太远”和“预计维护头痛”的行。

...这是我的建议：

如果你没有或没有，那么read the guide。
消息传递协议是困难的。看起来他们应该很容易，但他们很容易做错事。这就是为什么使用现成的协议可能是一个好主意即使在您看来效率较低。
不要过早优化。奇怪的是，额外的网络延迟不会成为您的瓶颈。你真正传递了多少数据？有没有办法可以卸载大部分数据？例如如果您要为每条消息发送 MB 的数据，是否可以将其存储在可集中访问的存储库中，然后仅在消息中发送 URI？
指南中列出了许多消息传递协议，并在 ZMQ 资源站点上免费提供。它们经过测试和精心设计。除非它们对您不起作用，否则请尝试使用它们。

如果您想让您提议的消息传递模式发挥作用，您需要为其添加套接字。每个进程都应该拥有一个传入和传出套接字（这将确保始终有偶数个套接字，并且 bind()ing 和 connect()ing 应该是可管理的。您将能够为每种套接字类型维护适当的消息传递（不打破 REQ 和 REP 的期望）通过添加另一个套接字来接收另一半的通信。但实际上，您应该查看现有协议并确定它们对您不起作用，并首先确定原因。

【讨论】：

【解决方案2】：

是的，但在其他合乎逻辑的问题中几乎没有注意事项

ZeroMQ 可以毫无问题地传递封装在消息负载中的任何节点的物理地址，但是有一些原因，为什么这并没有像它可能已经寻找第一眼那样直接解决您的愿望。

ZeroMQ 是一个功能强大的智能、可扩展、正式模式框架，用户可以在此框架之上构建她/他自己的消息传递系统。因此，使用正式模式（如 PUB/SUB 或 REQ/REP ）意味着您完全重用了它们的硬连线属性（它们的行为），而不仅仅是一半或三分之一。了解行为将使您能够构建您计划开发的更高层功能，但没有人可以（应该）损害 ZeroMQ 库原语 == 构建块的行为模型。它会破坏你的构建块的稳定性，因此宁愿集成任何新的更智能的附加功能“在顶部”功能齐全的原始关系，而不是试图在失去框架优势和稳健性的代价。
ZeroMQ 原语可以同时通过几个“传输类”连接到它的对方，这一事实对于应用程序逻辑是绝对透明的。这意味着，如果您的想法始于inproc:“已连接”REQ，那么您的地址传递/路由将无法在远端工作，其中REP 节点没有这样的传输类兼容路径到发起者和地址要么碰巧碰巧，要么一旦它在远程端不存在就无用，因此更快/更简单地将答案路由回请求者的预期好处（此时跳过麻烦一旦路由将跳过/绕过中间节点的轨迹段，因此在成对合作的对等点之间缺少“握手”，从而让它们等待响应，而这永远不会到来......）

去哪里了解更多详情？

在我看来，你可以做的最好的下一步是获得更多的全局视图，这对于尝试使用 ZeroMQ 编码的前几件事来说可能听起来很复杂，但如果你至少跳转到 Code Connected, Volume 1Code Connected, Volume 1 的strong>第 265 页，如果不是在那里一步一步阅读的话。

有史以来最快的学习曲线将是首先在 图 60 重新发布更新和 图 62 上获得未公开的视图strong> HA 克隆服务器对 用于可能的高可用性方法，然后返回到根源、元素和细节。

【讨论】：