[英]How to protect ZeroMQ Request Reply pattern against potential drops of messages?
我正在尝试在c#应用程序和分布式python服务器之间的TCP层上实现ZeroMQ模式。 我有一个使用请求 - 回复REQ/REP
模式的版本,在localhost
测试时看起来相对稳定。 但是,在测试中,我调试了一些情况,我在收到回复之前意外地发送了多个请求,这显然是不可接受的。
在实践中,网络可能会有大量丢弃的数据包,我怀疑我将丢弃大量的回复和/或无法发送请求。
1)有没有办法重置REQ/REP
请求 - 回复套接字 之间的连接 ?
REOUTER/DEALER
模式会更有意义吗? 由于这是我第一次使用ZeroMQ,我希望保持简单。
2)是否有一个良好的ZeroMQ机制来处理连接事件? 我一直在阅读“指南”,有一些关于监控连接的提及,但没有例子。 我找到了ZMonitor
,但无法在c#中触发事件。
广告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。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.