如何保护ZeroMQ请求回复模式以防止潜在的消息丢失？
我正在尝试在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|! | | !+------
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 !| |___| | : | !| |___| | : | !| |___| | : | !+------
广告2）不 ，
但是如果RTO测试无法certificate两个（多个）侧都已准备就绪，那么可以创建一个自己的“ZeroMQ耗材”来测试分布式系统设置新传输/信号sockets的能力， 准备好处理它+通过ZeroMQ基础设施进行通信 （注意，问题不仅在于ZeroMQ层，而且App端也不需要准备/处于这种状态以处理预期的通信交互（并且可能导致软锁/死 - 锁）。
最好的下一步？
我现在可以为你的进一步问题做些什么，可以指导你看到关于这个主题的更大的图片>>> 更多的论点 ，一个简单的信号平面/消息平面插图和一个必读书籍的直接链接 Pieter HINTJENS。