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

Question

我正在尝试在 c# 应用程序和分布式 python 服务器之间的 TCP 层上实现 ZeroMQ 模式。我得到了一个使用请求-回复 REQ/REP 模式的版本，在 localhost> 上测试时它似乎相对稳定/强>。然而，在测试中，我调试了一些情况，在这些情况下，我在收到显然 Not Acceptable 回复之前不小心发送了多个请求。

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

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

2) 是否有一个很好的 ZeroMQ 机制来处理连接事件？ 我一直在阅读“指南”，其中提到了一些监控连接，但没有示例。我找到了 ZMonitor，但无法在 c# 中触发事件。

Answer 1

广告 1) 否，
没有向用户公开任何套接字链接管理接口(interface)来测试/重置 ZeroMQ 框架中 FSA 到 FSA 链接的状态。

是的，XREQ/XREP 可以帮助您克服僵局，这在 REQ/REP 可扩展的正式通信模式中可能会发生并且确实会发生:

Ref.: REQ/REP Deadlocks >>> https://stackoverflow.com/a/38163015/3666197

图 1: 为什么使用天真的 REQ/REP
是错误的[1]in_WaitToRecvSTATE_W2R + [2]in_WaitToRecvSTATE_W2R 时的所有情况
主要是 REQ-FSA/REP-FSA Finite-State-Automata 无法挽救的相互死锁，永远不会到达“下一个”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 ~~~~~~~~~~~~~
|           ! /\/\/\/\/\/\/\/\/\/\/\|         |/\/\/\/\/\/\/\/\/\/\/!           |
|           ! \/\/\/\/\/\/\/\/\/\/\/|         |\/\/\/\/\/\/\/\/\/\/\!           |
+===========!=======================+         +=====================!===========+

---

图 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) 否，
但可以创建自己的“ZeroMQ-consumables”来测试分布式系统设置新传输/信令的能力套接字，准备好处理它，如果 RTO 测试未能证明双方(多)方已准备好通过 ZeroMQ 基础设施进行设置+通信(注意，问题不仅在于ZeroMQ 层，以及应用程序端不需要准备好/处于这种状态来处理预期的通信交互(并且可能导致软锁/死锁)。

---

最好的下一步是什么？

What I can do for your further questions right now is to direct you to see a bigger picture on this subject >>>包含更多论据、一个简单的信号平面/消息传递平面插图和来自 Pieter HINTJENS 的必读书籍的直接链接。