ZeroMQ 请求和对此请求的多个异步回复

Question

我有类似执行繁重计算的远程计算机和向其发送任务的客户端计算机。输出结果非常大，从兆字节到千兆字节，并且在很长一段时间内以块的形式出现。所以它看起来像这样：客户端发送任务，然后需要接收这些块，因为它们已经有用了（一个请求 - 多个响应）。如何在 ZeroMQ 中实现这种模式。

Answer 1

您可以使用异步模式 (DEALER-ROUTER)。

看这个话题The Asynchronous Client/Server Pattern

以及 Java or C#

中的示例

但请记住，如果达到 HWM，ROUTER 套接字可能会丢弃您的消息。

Answer 2

也许我读错了上面定义的问题，但就目前而言，在我看来主要关注的是实现一种方式来容纳一对主机之间的消息流（不是使用经典 DEALER/ROUTER 可扩展正式通信模式向 1+ Worker 扇出的 Broker），
哪里
关键问题是，如何处理
一个客户端机器（发送一个大计算任务请求和"waits"一个部分结果流）
到 HPC 机器（接收 TaskJOB，对其进行处理并将非同步、时间和大小消息流返回到客户端机器 ).

对于这样的 1:1 情况，使用 1-Job:many-partialJobResponses，该设置可能受益于联合消息传递和信令基础架构，其中包含多个实际套接字，如下图所示：

信令：

clientPUSH   |-> hpcPULL    // new TaskJOB|-> |
clientPULL <-|   hpcPUSH    //              <-|ACK_BEGIN
clientPULL <-|   hpcPUSH    //              <-|KEEPALIVE_WATCHDOG + PROGRESS_%
clientPULL <-|   hpcPUSH    //              <-|KEEPALIVE_WATCHDOG + PROGRESS_%
...                         //                |...
clientPULL <-|   hpcPUSH    //              <-|KEEPALIVE_WATCHDOG + PROGRESS_%
clientPULL <-|   hpcPUSH    //              <-|KEEPALIVE_WATCHDOG + PROGRESS_%
clientPULL <-|   hpcPUSH    //              <-|ACK_FINISH         + LAST_PAYLOAD#
clientPUSH   |-> hpcPULL    // new TaskJOB|-> |
clientPULL <-|   hpcPUSH    //              <-|ACK_BEGIN
...                         //                |...
clientPULL <-|   hpcPUSH    //              <-|ACK_FINISH         + LAST_PAYLOAD#

消息传递：

clientRECV <-|   hpcXMIT    //              <-|FRACTION_OF_A_FAT_RESULT_PAYLOAD#i
clientACK    |-> hpcACK     // #i POSACK'd|-> |
clientRECV <-|   hpcXMIT    //              <-|FRACTION_OF_A_FAT_RESULT_PAYLOAD#j
clientRECV <-|   hpcXMIT    //              <-|FRACTION_OF_A_FAT_RESULT_PAYLOAD#k
clientACK    |-> hpcACK     // #k POSACK'd|-> |
clientACK    |-> hpcACK     // #j   NACK'd|-> |
clientRECV <-|   hpcXMIT    //              <-|FRACTION_OF_A_FAT_RESULT_PAYLOAD#j
clientACK    |-> hpcACK     // #j POSACK'd|-> |
clientACK    |-> hpcACK     // #u   NACK'd|-> |               // after ACK_FINISH
clientACK    |-> hpcACK     // #v   NACK'd|-> |               // after ACK_FINISH
clientACK    |-> hpcACK     // #w   NACK'd|-> |               // after ACK_FINISH
clientACK    |-> hpcACK     // #x   NACK'd|-> |               // after ACK_FINISH
clientRECV <-|   hpcXMIT    //              <-|FRACTION_OF_A_FAT_RESULT_PAYLOAD#x
clientACK    |-> hpcACK     // #x POSACK'd|-> |
clientRECV <-|   hpcXMIT    //              <-|FRACTION_OF_A_FAT_RESULT_PAYLOAD#u
clientACK    |-> hpcACK     // #u POSACK'd|-> |
...                         //                | ...      
clientRECV <-|   hpcXMIT    //              <-|FRACTION_OF_A_FAT_RESULT_PAYLOAD#w
clientACK    |-> hpcACK     // #w POSACK'd|-> |

同样，将一对 PUSH/PULL 套接字用于（内部）无状态消息自动机，但允许一个人创建自己的、更高级别的有限状态自动机，用于自我修复消息流，将 FAT_RESULT 控制的碎片处理成更容易吞噬的有效负载（记住 ZeroMQ 的一条格言，使用零保证而不是构建不可扩展的乳齿象（野生生态系统的进化本质无论如何都会杀死）并且还提供一定程度的按需反应重新传输。

为了提高处理吞吐量，一些甚至更智能的多代理设置不远了（FAT_RESULT DataFlow Curator 代理，与HPC_MAIN分开，卸载HPC平台的资源以立即启动下一个TaskJOB等)

ZeroMQ 请求和对此请求的多个异步回复

ZeroMQ request and multiple async replies to this request

asynchronous

design-patterns

zeromq

信令：

消息传递：