[zeromq-dev] ZMQ_MCAST_LOOP with PGM

Steven McCoy steven.mccoy at miru.hk
Tue Aug 7 04:19:39 CEST 2012

On 6 August 2012 08:19, Pierre Ynard <linkfanel at yahoo.fr> wrote:

> <CAGFWLih5Cz87R5S51WxEnAsA6VLbKBxtuHPnD=RQjaiE-2SEcA at 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

> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120806/d752c3a9/attachment.htm>

More information about the zeromq-dev mailing list