如何保護ZeroMQ請求回復模式以防止潛在的消息丟失？

Question

我正在嘗試在c＃應用程序和分布式python服務器之間的TCP層上實現ZeroMQ模式。 我有一個使用請求 - 回復REQ/REP模式的版本，在localhost測試時看起來相對穩定。 但是，在測試中，我調試了一些情況，我在收到回復之前意外地發送了多個請求，這顯然是不可接受的。

在實踐中，網絡可能會有大量丟棄的數據包，我懷疑我將丟棄大量的回復和/或無法發送請求。

1）有沒有辦法重置REQ/REP請求 - 回復套接字 之間的連接 ？
REOUTER/DEALER模式會更有意義嗎？ 由於這是我第一次使用ZeroMQ，我希望保持簡單。

2）是否有一個良好的ZeroMQ機制來處理連接事件？ 我一直在閱讀“指南”，有一些關於監控連接的提及，但沒有例子。 我找到了ZMonitor ，但無法在c＃中觸發事件。

Answer 1

廣告1）不 ，
沒有任何套接字鏈接管理接口向用戶公開，以測試/重置ZeroMQ框架中FSA到FSA鏈路的狀態。

是的， XREQ/XREP可以幫助您克服在REQ/REP可擴展形式通信模式中可能發生和可能發生的死鎖：

參考： REQ/REP死鎖>>> https://stackoverflow.com/a/38163015/3666197

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層，而且App端也不需要准備/處於這種狀態以處理預期的通信交互（並且可能導致軟鎖/死 - 鎖）。

---

最好的下一步？

我現在可以為你的進一步問題做些什么，可以指導你在這個主題上看到更大的圖片>>> 更多的論點 ，一個簡單的信號平面/消息平面插圖和一個必讀書籍的直接鏈接 Pieter HINTJENS。