CODEWITHSUNDEEP
javacnetwork-programmingzeromqdistributed-computing
cubuspl42
cubuspl42

Reputation: 8360

Can reply be optional in ZeroMQ?

I'm implementing a Lamport's distributed MUTEX algorithm in ZeroMQ.

Algorithm :

Requesting process

1 ) Pushing its request in its own queue (ordered by time stamps)
2 ) Sending a request to every node.
3 ) Waiting for replies from all other nodes.
4 ) If own request is at the head of its queue and all replies have been received, enter critical section.
5 ) Upon exiting the critical section, remove its request from the queue and send a release message to every process.

Other processes

1 ) After receiving a request, pushing the request in its own request queue (ordered by time stamps) and reply with a time stamp.
2 ) After receiving release message, remove the corresponding request from its own request queue.

I'm considering coding the solution in C or Java, but the core of the problem seems to be language-neutral.

In my problem, I have three message types, let's call them Request, Reply and Release. The Request/Reply messages fit well into REQ/REP pattern, but the Release message is one-way signal and does not need a reply. I could add an additional PUB/SUB pair, but then, in my understanding, I will not have the guarantee of FIFO delivery order in the system, because I would end up having two concurrent TCP connections (is this assumption right?).

I could make use of a basic non-constrained fullduplex channel. Another answer suggests using DEALER/ROUTER pair, but it seems like an overkill for such a simple problem. In docs, DEALER/ROUTER is described in Advanced Request-Reply Patterns chapter, and my problem doesn't seem to need an extreme solution.

How can my problem be solved?

Upvotes: 1

Views: 189

Answers (1)

user3666197
user3666197

Reputation: 1

"Can reply be optional in ZeroMQ?"

Short version: Can.

just set properly .setsockopt( zmq.REQ_RELAXED, 1 )

Longer version:

There will be more issues yet to be solved for defined problem, if indeed distributed-system ought gain robustness. REQ/REP need not fall into a principally unsalvageable mutual-deadlock, as a distributed-FSA was shortcut with .REQ_RELAXED settings, yet ZeroMQ does not provide warranty for a message delivery. It is a best-effort delivery, so you need to implement a higher-level protocol handshaking, if in a need for a guaranteed message delivery. Setting .setsockopt( zmq.REQ_CORRELATE, 1 ) may help in this.

Upvotes: 1

Related Questions