如何保护ZeroMQ请求回复模式以防止潜在的消息丢失？

Question

我正在尝试在c#应用程序和分布式python服务器之间的TCP层上实现ZeroMQ模式.我有一个使用请求 - 回复模式的版本,在测试时看起来相对稳定.但是,在测试中,我调试了一些情况,我在收到回复之前意外地发送了多个请求,这显然是不可接受的.REQ/REPlocalhost

在实践中,网络可能会有大量丢弃的数据包,我怀疑我将丢弃大量的回复和/或无法发送请求.

1)有没有办法重置REQ/REP请求 - 回复套接字之间的连接？
一种REOUTER/DEALER模式会更有意义吗？由于这是我第一次使用ZeroMQ,我希望保持简单.

2)是否有一个良好的ZeroMQ机制来处理连接事件？ 我一直在阅读"指南",有一些关于监控连接的提及,但没有例子.我找到了ZMonitor,但无法在c#中触发事件.

Answer 1

Ad 1)否,
没有任何套接字链接管理接口向用户公开,以测试/重置ZeroMQ框架中FSA到FSA链路的状态.

是的,XREQ/XREP可以帮助您克服在REQ/REP可扩展的正式通信模式中可能发生和可能发生的死锁:

参考:REQ/REP死锁>>> /sf/answers/2671411081/

Fig.1:当+ 主要是有限状态自动机的不可解决的相互死锁并且永远不会达到"下一个" 内部状态时,为什么使用天真的所有情况都是错误的.REQ/REP
[1]in_WaitToRecvSTATE_W2R[2]in_WaitToRecvSTATE_W2R
REQ-FSA/REP-FSAin_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+------+!           |
|           !                       |   :     |                     !           |
|           !                       |   :     |                     !           |
+===========!=======================+   :     +=====================!===========+

Ad 2)否,
但是如果RTO测试无法证明两者(多个),则可以创建一个自己的"ZeroMQ耗材"来测试分布式系统设置新传输/信令插座的能力,准备好处理它双方已经准备好建立+通过ZeroMQ基础设施进行通信(注意,问题不仅在于ZeroMQ层,而且App侧也不需要准备/处于这种状态以处理预期的通信交互(并且可能导致软锁/死锁).

最好的下一步？

我能为你进一步的问题,现在做是引导你看到一个关于这个问题>>>更大的画面与更多的参数,一个简单的信令平面/消息面插图和直接链接到必读的书,从Pieter HINTJENS.