7

I have a small cluster of peers (e.g. 10 nodes) already publishing and subscribing for messages. This is working fine. The cluster is static and every node knows the address of the other nodes.

In my use-case I also need all the nodes to be able to send messages to any specific node, and all the nodes should listen for messages addressed to them. The sending node does not need a reply, should not have to wait for a reply and does not need to know that the other node has received the message.

What kind of pattern and socket types could be used to implement this?

I am quite new to ØMQ, and have looked the Freelance Pattern from the guide, more specifically Model Three - Complex and nasty. Is using the ROUTER-ROUTER approach described there appropriate in my case?

I'm thinking of letting every node bind to a ROUTER socket setting their address a identity (and "polling" it into their message loop), and also letting the node send on a ROUTER socket, specifying the receiving node address as identity.

Have I missed some simpler way of doing this? Using the approach above seems maybe a bit complex since I really don't need the handshake procedure giving the receiving end ability to send a reply.

tle
  • 95
  • 1
  • 5

1 Answers1

2

For sending work to a peer without needing a reply, I'd probably just use a Fanout pattern, which will let you more effectively "fire and forget".

Router and Dealer are really there for the "device" tier in an "extended" request / reply pattern.

Shaun
  • 3,928
  • 22
  • 21
  • Maybe I'm missing something here, but how does fan-out let me send a message to only a specific node? – tle Apr 02 '12 at 11:07
  • 2
    You'd only have one node doing the PULL rather than a series of nodes. In other words, when you need to employ the "specific node" use case, you have a single PUSH and single PULL pair. There's no expectation when doing a PUSH that you receive anything in return, so in my mind it's a better async metaphor than REQ/REP. You could also to a PUB/SUB between single nodes if you just want to reuse what you've already got, architecturally. – Shaun Apr 02 '12 at 19:27
  • 1
    PUSH-PULL will not drop messages if the recipient is down, as per the doc, which means if your remote node goes down (the peer you're sending to) and comes back, it'll get a bunch of old messages. You can of course mitigate this problem by keeping track of the up-down status of the recipient (by means of heartbeat, or equivalent), and closing the PUSh socket as soon as the node goes down (with linger=0 possibly). – Erik Kaplun Sep 07 '12 at 08:10
  • which one do you mean by Fanout pattern? any example link? – Louis Rhys Apr 16 '13 at 02:21
  • The best suggestion I can give is to check out the excellent ZeroMQ guide: http://zguide.zeromq.org/page:all In general though, fan-out/fan-in are common messaging patterns supported by a variety of message oriented architectures. – Shaun Apr 16 '13 at 16:39
  • Just a little more info for you: Fan-out/fan-in are supported by ZeroMQ via the PUSH/PULL socket types. RabbitMQ, on the other hand, has the 'fanout' exchange type. Hope this helps. – Shaun Apr 16 '13 at 16:45