On 6 August 2012 08:19, Pierre Ynard <[email protected]> wrote: > <CAGFWLih5Cz87R5S51WxEnAsA6VLbKBxtuHPnD=rqjaie-2s...@mail.gmail.com> > > > It's been removed because of discussions like this > > This is now a discussion about the underlying issues of the PGM > transport, not limited to ZMQ_MCAST_LOOP. Removing the option that made > the issue most visible so that people don't complain about it is just > sweeping under the rug. >
It's both, because no amicable resolution has been found and over ten years of engineering has only come up with the solutions already presented. > > 0MQ makes a host broker trivial to implement: the method other > > middleware systems resolve this issue: TIBCO's Rendezvous Daemon for > > example. > > ZeroMQ is advertised as zero broker, zero configuration, N-to-N > communication... but surprisingly enough at some point I always stumble > upon "easy, just use a broker!" I don't want a broker, I don't want more > complexity in my system and I don't want to code and monitor an extra > daemon. > This is why you can bind IPC, ITC, TCP, and PGM to the same socket. > I want to run several instances of the same process in parallel for > redundancy and scalability reasons. So they do the same job and want to > send data to the same destination, so same port. Also, that's a reason > why I'm not interested in adding a new SPOF downstream to that. Redundancy on the same host is retarded you are wasting resources to catch less 0.01% error scenarios that don't bring down the entire host or network;scaling sounds like a bad design: split the channel up into many separate PGM sessions with rate limited senders and your data stream load balanced across them. It is becoming popular to automate this load-balancing but 0MQ does not yet implement such a feature: TIBCO Rendezvous 8 does. > There is no real reason why UDP would be worse with loopback. And with > loopback the only cause I see for this is receive buffer overrun. > The UDP loopback network stack is broken for anything above minimal transfer rates. It has been this way a long time and can be easily reproduced with multicast testing tools. Windows fairs better as sockets are handled outside of the kernel but performance is significantly worse. > Besides, > many local DNS resolvers are reached by loopback UDP, and - correct me > if I'm missing something - I don't think they're considered as terrible. > They're reached through the NSS subsystem or TCP and the data rates are minimal. > The fact that more reliable options are available on the local host > doesn't make UDP loopback bad either. Unless we're talking about ZeroMQ > seamlessly emulating a faulty local UDP channel with a better transport > in parallel behind the scenes, then yeah, maybe. On Solaris and other UNIX flavours this is true, however as noted before on Linux it is broken. If you follow 29 West there are other better methods available: it is possible to implement a broadcast IPC ring buffer for very fast ultra low-latency that doesn't touch the kernel like loopback UDP would and scales beyond the unicast channel 0MQ currently provides. -- Steve-o
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
