[zeromq-dev] Possible to Build Actual N-to-N Topology?

[Yi Ding]

On Fri, Jan 27, 2012 at 2:24 AM, Jakub Witkowski <jpw at jabster.pl> wrote:

> Hello,
>
> 2012/1/26 Martin Sustrik <sustrik at 250bpm.com>:
> > On 01/26/2012 11:13 AM, Michael Craig wrote:
> >> In a bunch of the marketing copy, ZeroMQ claims to handle N-to-N
> >> topologies. Is this actually true? It would seem not, since one side of
> >> a Push/Pull or Pub/Sub topology has to bind (which only one node can
> >> do). The closest I can figure out is an N-to-1-to-N topology with some
> >> kind of router in the middle. Does ZeroMQ actually provide some way to
> >> eliminate that single point of failure in the middle?
> >
> > You can have a device in a middle or you can use multicast which boils
> > down to using network switch as a device in the middle.
> >
> > A solution to eliminate SPoFs that's used quite often in environments
> > with high reliability requirements is to have 2 network switches and 2
> > NICs in each box (each NIC is connected to each switch). That kind of
> > setup, combined with each 0MQ endpoint being connected to all the other
> > 0MQ endpoints does the job.
> >
> > It's of course a nightmare to manage, but sometimes the reliability
> > requirements are so high you want to go that way.
> >
>
> In a more distributed and less "enterprisey" environment, one can
> imagine using some discovery protocol (broadcast, zeroconf, DNS...) to
> help autoconfigure nodes; there's nothing inherently limiting N-to-N
> situations in ZeroMQ but, at the same time, the library does not do
> peer searching for you.
>
> For a truly homogeneous setup, you probably will need two sockets per
> node, one PUB and one SUB, with some connect-back algorithm.
>
> Agreed.  There are a couple of caveats with the one PUB, one SUB model.

1) The current recommended way to do discovery in the guide is to set up a
directory server.  Building an appropriate directory server is tricky
though because zeromq currently does not allow the user to see what the
IP/port of a sender is, so a sender needs to get its own IP (which can be a
bit non-deterministic) and send it in the message body to the directory
server, which can then broadcast it out.

2) ZMQ PUB/SUB has the slow joiner issue.  The recommended way to handle
slow joiners is to use a different port to do the synchronization, which
means you end up requiring an additional PUSH/REQ/ROUTER port per node you
want to synchronize with.  This will go away in ZMQ 3 as the subscription
message can substitute for the synchronization message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120127/3a65d44c/attachment.htm>