1

I am very much new to the ZeroMQ library.

Hence I wanted to know the pattern ( REQ-REP, PUSH-PULL, PUB-SUB ) that will be the best for our application.

The application which we are using has two systems,
the one which the user interacts with
and
the second is the scheduler, which executes a job, scheduled by the user in the first system.

Now I want to make use of ZeroMQ to send messages in the below scenarios:

  1. from userSystem to schedulerSystem that a job with particular job id is submitted for execution.

  2. from schedulerSystem to userSystem that the job sent with a particular job id has been executed succesfully or the execution has failed

Can somebody please help with this,
stating the reason for using a particular pattern?

Thanks in advance.

user3666197
  • 1
  • 6
  • 50
  • 92
Ann
  • 303
  • 1
  • 3
  • 15
  • Did you read the guide? This topic is covered there. Long story short, the efficient types would be `PUSH` and `PULL` combinations. Since those two are usually difficult for people, there exists a combination of two socket types `ROUTER` and `DEALER` which "look" like `REQ` and `REP` but are asynchronous under the hood. It means it's easy to implement and it's efficient. [Follow this link](http://zguide.zeromq.org/php:chapter3) and look for **figure 38**. – Mjh Oct 28 '15 at 11:27
  • @Mjh: Thank you so much. We started out trying with the ROUTER- DELAER model, but later on requirment of persisting the the messages was added . So now we are exploring the "Disconnected Reliability (Titanic Pattern) given in the [link](http://zguide.zeromq.org/php:chapter4) – Ann Oct 30 '15 at 11:26
  • I'm glad you have it working, have fun using ZMQ :) – Mjh Oct 30 '15 at 11:57

1 Answers1

0

Which is the best Formal Communication Pattern to use? None...

Dear Ann,

with all due respect, nobody would try to seriously answer a question which of all the possible phone numbers is the best for any kind of use.

Why? There is simply no Swiss-Army-Knife for doing just anything.

That is surprisingly the good news. As a system designer one may create The Right Solution on a green-field, using the just-enough design strategies for not doing more than necessary ( overhead-wise ) and have all the pluses on your design side ( scaleability-wise, low-latency-wise, memory-footprint-wise, etc. )

If no other requirements than (1) and (2) above appear,
a light-weight scheme
like this may work fine as an MVP "just-enough" design:

If userSystem does not process anything depending on a schedulerSystem output value, a PUSH-PULL might be an option for sending a job, with possible extensions.

For userSystem receiving independent, asynchronously organised state-reporting messages about respective jobID return code(s), again a receiver side poll-ed PUSH-PULL might work well.

Why? Otherwise natural unstructured behaviour-wise PAIR-PAIR disallows your processing from growing in scale once performance or architecture or both demand to move. PAIR-PAIR does not allow your communication framework to join more entities together, while others do and your processing power may go distributed until your IP-visibility and end-to-end latency permit.

The real world is typically much more complex

Just one picture, Fig.60 from the below-mentioned book:
enter image description here

The best next step?

To see a bigger picture on this subject >>> with more arguments, a simple signalling-plane picture and a direct link to a must-read book from Pieter HINTJENS.

Community
  • 1
  • 1
user3666197
  • 1
  • 6
  • 50
  • 92