如何保护 ZeroMQ 请求回复模式免受潜在的消息丢失?-C#/.NET问题

How to protect ZeroMQ Request Reply pattern against potential drops of messages?(如何保护 ZeroMQ 请求回复模式免受潜在的消息丢失?)

本文介绍了如何保护 ZeroMQ 请求回复模式免受潜在的消息丢失?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

我正在尝试在 c# 应用程序和分布式 python 服务器之间的 TCP 层上实现 ZeroMQ 模式.我得到了一个使用请求-回复 REQ/REP 模式的版本，在 localhost.但是，在测试中，我调试了一些情况，在收到显然不可接受的回复之前，我不小心发送了多个请求.

I'm trying to implement a ZeroMQ pattern on the TCP layer between a c# application and distributed python servers. I've gotten a version working with the request-reply REQ/REP pattern and it seems relatively stable when testing on localhost. However, in testing, I've debugged a few situations, where I accidently send multiple requests before receiving a reply which apparently is not acceptable.

实际上，网络可能会丢弃大量数据包，我怀疑我会丢弃大量回复和/或无法发送请求.

1) 有没有办法重置 REQ/REP request-reply sockets 之间的连接?
REOUTER/DEALER 模式更有意义?由于这是我第一个使用 ZeroMQ 的应用程序，我希望保持简单.

1) Is there a way to reset the connection between REQ/REP request-reply sockets?
Would a REOUTER/DEALER pattern instead make more sense? As this is my first application with ZeroMQ, I was hoping to keep it simple.

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

2) Is there a good ZeroMQ mechanism for handling the connectivity events? I've been reading "the guide" and there are a few mentions of monitoring connections, but no examples. I found the ZMonitor, but can't get the events to trigger in c#.

推荐答案

Ad 1) No,
没有任何socket链接管理接口暴露给用户测试/重置状态ZeroMQ 框架中的 FSA 到 FSA 链接.

Ad 1) No,
there is not any socket link-management interface exposed to user to test/reset the state of the FSA-to-FSA link in ZeroMQ framework.

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

Yes, XREQ/XREP may help you overcome the deadlocks, that may & do happen in REQ/REP Scaleable Formal Communication Pattern:

参考:REQ/REP 死锁>>> https:///stackoverflow.com/a/38163015/3666197

图 1: 为什么使用幼稚的 REQ/REP
all 是错误的[1]in_WaitToRecvSTATE_W2R + [2]in_WaitToRecvSTATE_W2R
主要是 REQ-FSA/REP-FSA Finite-State-Automata 无法挽救的相互死锁，永远不会到达下一个"in_WaitToSendSTATE_W2S 内部状态.

Fig.1: Why it is wrong to use a naive REQ/REP
all cases when [1]in_WaitToRecvSTATE_W2R + [2]in_WaitToRecvSTATE_W2R
are principally unsalvageable mutual deadlock of REQ-FSA/REP-FSA Finite-State-Automata and will never reach the "next" in_WaitToSendSTATE_W2S internal state.

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 层工具完全控制所有可能的分布式系统状态.

Fig.2: One may implement a free-stepping transmission layer using several pure ZeroMQ builtins and add some SIG-layer tools for getting a full control of all possible distributed system states.

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

App1.PULL.recv( ZMQ.NOBLOCK ) and App1.PULL.poll( 0 ) are obvious

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

Ad 2) No,
but one may create one's own "ZeroMQ-consumables" to test the distributed system's ability to setup a new transport/signalling socket, being ready to dispose it, if the RTO-test fails to prove that both ( multiple ) sides are ready to setup + communicate over the ZeroMQ infrastructure ( notice, that the problems are not only with the ZeroMQ layer, but also the App-side need not be ready/in such a state to handle the expected communication interactions ( and may cause soft-locks / dead-locks ).

对于您的进一步问题，我现在可以做的是指导您查看关于此主题的更大图景>>> 带有更多参数、一个简单的信号平面/消息平面插图和一个必读书籍的直接链接 来自 Pieter HINTJENS.

What I can do for your further questions right now is to direct you to see a bigger picture on this subject >>> with more arguments, a simple signalling-plane / messaging-plane illustration and a direct link to a must-read book from Pieter HINTJENS.

这篇关于如何保护 ZeroMQ 请求回复模式免受潜在的消息丢失?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！