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

也许我读错了上面定义的问题，但就目前而言，在我看来，主要关注的是实现一种方法来容纳一对主机之间的消息流（而不是使用经典的DEALER/ROUTERScaleable将 Broker 扇出到 1+ Workers正式通信模式），
其中，
关心的重点是，如何处理
一个客户机（发送一个大计算任务请求用于部分结果的流动和“等待”）
以一个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_RESULTDataFlow Curator 代理，与 分离HPC_MAIN，卸载 HPC 平台的资源以立即开始下一个TaskJOB等）