如何保护ZeroMQ请求回复模式免受潜在的消息丢失的影响？

Question

我正在尝试在 c＃* 应用程序和分布式 python 服务器之间的TCP层上实现 ZeroMQ 模式。我有一个使用request-
reply模式的版本，在上进行测试时似乎相对稳定。但是，在测试中，我调试了一些情况，在收到回复之前，我偶然发送了多个请求，这显然是不可接受的。


*REQ/REP localhost

在实践中，网络可能会丢掉很多数据包，我怀疑我会丢掉很多答复和/或无法发送请求。

1）有没有一种方法可以重置REQ/REP请求-答复 套接字 之间的连接 ？
将一个REOUTER/DEALER模式，而不是更有意义？因为这是我使用ZeroMQ的第一个应用程序，所以我希望保持简单。

2）是否存在用于处理连接事件的良好ZeroMQ机制？ 我一直在阅读“指南”，其中提到了一些监视连接的信息，但没有示例。我找到了
ZMonitor ，但无法在c＃中触发事件。

Answer 1

广告1）不 ，
用户没有任何套接字链接管理接口可以测试/重置ZeroMQ框架中FSA到FSA的状态。

是的， XREQ/XREP 可以帮助您克服僵局，在REQ/REP可伸缩的正式沟通模式中可能会发生以下情况：

Fig.1: 为什么在+主要是有限状态自动机的相互死锁且永远不会到达“下一个”内部状态的情况下，天真地使用所有情况都是错误的。
REQ/REP
[1] in_WaitToRecvSTATE_W2R[2] in_WaitToRecvSTATE_W2R
REQ-FSA/REP-FSA in_WaitToSendSTATE_W2S

               XTRN_RISK_OF_FSA_DEADLOCKED ~ {  NETWORK_LoS
                                         :   || NETWORK_LoM
                                         :   || SIG_KILL( App2 )
                                         :   || ...
                                         :      }
                                         :
[App1]      ![ZeroMQ]                    :    [ZeroMQ]              ![App2] 
code-control! code-control               :    [code-control         ! code-control
+===========!=======================+    :    +=====================!===========+
|           ! ZMQ                   |    :    |              ZMQ    !           |
|           ! REQ-FSA               |    :    |              REP-FSA!           |
|           !+------+BUF> .connect()|    v    |.bind()  +BUF>------+!           |
|           !|W2S   |___|>tcp:>---------[*]-----(tcp:)--|___|W2R   |!           |
|     .send()>-o--->|___|           |         |         |___|-o---->.recv()     |
| ___/      !| ^  | |___|           |         |         |___| ^  | |!      \___ |
| REQ       !| |  v |___|           |         |         |___| |  v |!       REP |
| \___.recv()<----o-|___|           |         |         |___|<---o-<.send()___/ |
|           !|   W2R|___|           |         |         |___|   W2S|!           |
|           !+------<BUF+           |         |         <BUF+------+!           |
|           !                       |         |                     !           |
|           ! ZMQ                   |         |   ZMQ               !           |
|           ! REQ-FSA               |         |   REP-FSA           !           |
~~~~~~~~~~~~~ DEADLOCKED in W2R ~~~~~~~~ * ~~~~~~ DEADLOCKED in W2R ~~~~~~~~~~~~~
|           ! /\/\/\/\/\/\/\/\/\/\/\|         |/\/\/\/\/\/\/\/\/\/\/!           |
|           ! \/\/\/\/\/\/\/\/\/\/\/|         |\/\/\/\/\/\/\/\/\/\/\!           |
+===========!=======================+         +=====================!===========+

Fig.2: 可以使用几个纯ZeroMQ内置函数来实现自由步进传输层，并添加一些SIG层工具以完全控制所有可能的分布式系统状态。

App1.PULL.recv( ZMQ.NOBLOCK ) 而且 App1.PULL.poll( 0 ) 很明显

[App1]      ![ZeroMQ]
code-control! code-control           
+===========!=======================+
|           !                       |
|           !+----------+           |         
|     .poll()|   W2R ___|.bind()    |         
| ____.recv()<----o-|___|-(tcp:)--------O     
| PULL      !|      |___|           |   :   
|           !|      |___|           |   :   
|           !|      |___|           |   :   
|           !+------<BUF+           |   :     
|           !                       |   :                           ![App2]
|           !                       |   :     [ZeroMQ]              ! code-control
|           !                       |   :     [code-control         ! once gets started ...
|           !                       |   :     +=====================!===========+
|           !                       |   :     |                     !           |
|           !                       |   :     |         +----------+!           |
|           !                       |   :     |         |___       |!           |
|           !                       |   :     |         |___| <--o-<.send()____ |
|           !                       |   :<<-------<tcp:<|___|   W2S|!      PUSH |
|           !                       |   :    .connect() <BUF+------+!           |
|           !                       |   :     |                     !           |
|           !                       |   :     |                     !           |
+===========!=======================+   :     +=====================!===========+

广告2）否 ，
但是 如果RTO测试无法证明这两个（多个），则 可以创建自己的 “ ZeroMQ消耗品” 来测试分布式系统设置新的传输/信令套接字的能力，
并准备对其进行处理。双方准备通过ZeroMQ基础架构进行设置+进行通信
（请注意，问题不仅在于ZeroMQ层，而且应用程序方面也不需要处于就绪状态/处于这样的状态以处理预期的通信交互（并且可能导致软锁/死锁）。

最好的下一步？

我能为你进一步的问题，现在做是引导你看到一个 **关于这个问题

更大的画面与 更多的参数 ，一个简单
的信令平面/消息面插图 和 直接链接到必读的书** ，从Pieter HINTJENS。