All geek questions in one place

How to protect a ZeroMQ query request template from possible message drops?

I am trying to implement a TCP -level ZeroMQ pattern between a C # application and a distributed python server. I got a version that works with the REQ/REP pattern with a request-response, and it looks relatively stable when testing on localhost . However, when testing, I debugged several situations where I accidentally sent several requests before receiving an answer that, apparently, was unacceptable.

In practice, there are likely to be many dropped packets on the network, and I suspect that I will drop many responses and / or cannot send requests.

1) Is there a way to reset the connection between REQ/REP socket response requests ?
Will the REOUTER/DEALER pattern make more sense instead? Since this is my first ZeroMQ application, I was hoping to keep it simple.

2) Is there a good ZeroMQ mechanism for handling connection events? I read the "manual" and there are a few mentions about monitoring connections, but there are no examples. I found ZMonitor , but can't get events to fire in C #.

+4
source share
1 answer

Announcement 1) No , and there is no socket connection control interface prone to testing / reset the FSA-FSA link state in the ZeroMQ environment.

Yes, XREQ/XREP can help you overcome deadlocks that can and do happen in the REQ/REP Scalable Formal Communication Pattern:

Ref .: REQ/REP Deadlocks →> fooobar.com/questions/1260924 / ...

Fig.1: Why it is not recommended to use naive REQ/REP in all cases when [1] in_WaitToRecvSTATE_W2R + [2] in_WaitToRecvSTATE_W2R is a fundamentally untenable mutual deadlock REQ-FSA/REP-FSA Finate-State-Automata and 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 ~~~~~~~~~~~~~ | ! /\/\/\/\/\/\/\/\/\/\/\| |/\/\/\/\/\/\/\/\/\/\/! | | ! \/\/\/\/\/\/\/\/\/\/\/| |\/\/\/\/\/\/\/\/\/\/\! | +===========!=======================+ +=====================!===========+

Fig.2: . Fig.2: You can implement the transparent transfer level using several clean built-in ZeroMQ functions and add some SIG level tools to gain complete control over all possible distributed system states.

App1.PULL.recv( ZMQ.NOBLOCK ) and App1.PULL.poll( 0 ) 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+------+! | | ! | : | ! | | ! | : | ! | +===========!=======================+ : +=====================!===========+

Announcement 2) No , but you can create one of your own "ZeroMQ-consumables" to test the ability of a distributed system to configure a new connector for transmission / signaling, ready to remove it if the RTO test cannot prove that both (several) parties are ready for configuring + exchange information through ZeroMQ infrastructure (note that the problems associated not only with ZeroMQ layer, but also the application side need not be ready / in such a state for handling the expected communication interactions (and may cause the locking / blo irovki).

Best next step?

What I can do for your further questions right now is to direct you to a larger picture on this topic →> with more arguments , a simple illustration of a signal plane / message plane and a direct link to a required book from Pieter HINTJENS. p>

+4
source

Source: https://habr.com/ru/post/1260914/

More articles:


All Articles