1

I have a requirement where a master process needs to send commands to slave process and slave process needs to acknowledge. I am trying to use request-response pattern in ZMQ by making master as the response server and slave as the requesting client. But everytime slave needs to request the master for commands which is not desirable. And I am not sure if there are any expiry time for the request. I just want a full duplex communication between two process. What other alternatives are better than this?

Note : My master is written in C and slave is in C#.

prashanthns
  • 339
  • 2
  • 12
  • Is it windows specifically or multiplatform? – mrogal.ski Mar 17 '17 at 10:05
  • Currently on windows. I would prefer it to be easily portable on Linux. – prashanthns Mar 17 '17 at 10:07
  • On windows you can use internal message pump ( `WndProc` ) with combination of `SendMessage`. But then to port this to other platform I think the better way would be to use standard IO or even Shared Memory. – mrogal.ski Mar 17 '17 at 10:09
  • Take a look at [this So post](http://stackoverflow.com/questions/1906166/inter-process-communication-recommendation). BTW to be portable and efficient I suggest you to write your IPC layer based on platform. It grants to apply the best techninc for the target paltform. – LPs Mar 17 '17 at 10:44
  • You are stating a requirement for **not** using a master-slave protocol. Getting the design so drastically wrong is rather a big deal, you *must* talk to whomever made this decision. If nobody picks up the telephone then just create two queues. – Hans Passant Mar 17 '17 at 12:45
  • Is there a single master and multiple slaves? Are all the slaves the same, or does the master need to be able send messages to specific slaves? – colini Mar 18 '17 at 12:02
  • @colini Yes. There are more than one slaves and they are not same. Each slave process performs different tasks. – prashanthns Mar 21 '17 at 12:09

2 Answers2

1

Using one particular ZeroMQ archetype
having a hardwired Scaleable Formal Communication Pattern behaviour
makes sense only in case the both agent-side behaviours match the archetype ones.

This means, whenever a free-form ( ad-hoc ) behaviours ought be possible, forget straight about using the REQ/REP et al.

One can enjoy PUSH/PULL tandems or PAIR/PAIR patterns, where your agents do not headbang into some hard-coded message ordering or a deadlock of waiting for a never answered / lost message before being able to .send() and get delivered a next one to it's distributed counterparty.

Yes, it will make you to design your own message counting, timeouts, service watchdog / keepalive signalling, message-resending and similar robustness motivated strategies, but that's the bread & butter in distributed computing, isn't it?

Anyway, enjoy this wild ride into distributed computing & may be interested in other related posts on power-usage of ZeroMQ tools ( incl. a ref. to an excellent book from Pieter HINTJENS - "Code Connected, Vol. 1" --- a must read ...

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

Given that the master must be able to send messages to specific slaves, I recommend this approach. The master will bind a single ROUTER socket. Each slave will connect to the master ROUTER using a single DEALER socket. (So the slaves must know the master's address and ROUTER port.)

After connecting each slave will send some kind of "hello" message to the master to let the master know what type of slave it is (or, what types of tasks it can perform). Now as slaves come online the master will know what type they are and will be able to send them messages.

This is a fairly advanced ZeroMQ configuration. Before you attempt this I recommend that you write a very basic master/slave application with a ROUTER and DEALER socket pair. You should read at least Chapters 1-3 of the guide. At a minimum you must understand how ROUTER sockets work

colini
  • 736
  • 8
  • 11