On Fri, Jan 27, 2012 at 2:24 AM, Jakub Witkowski <[email protected]> wrote:
> Hello, > > 2012/1/26 Martin Sustrik <[email protected]>: > > 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.
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
