[zeromq-dev] IPv6 multicast RADIO/DISH

Lionel Flandrin lionel at svkt.org
Thu Apr 26 18:21:05 CEST 2018

On Thu, Apr 26, 2018 at 08:49:17AM -0400, Brian Adamson wrote:
> Hi Lionel,
> Although it isn’t yet supported with the ZMQ API’s, the NORM
> protocol can be configured with receiver feedback disabled to
> provide an unreliable UDP-like best effort service with the added
> benefit of its message fragmentation and reassembly when messages
> are larger than the network MTU.  Additionally the FEC-based packet
> erasure coding can also be invoked if desired to provide a
> quasi-reliable “better than best effort” service where a number of
> FEC parity packets per coding block (where a “block” is a block of
> packets) can be set that are sent in addition to the user data
> packets.  It would be interesting to explore adding some additional
> options for the NORM binding.  I haven’t had time to spend on that
> but would be happy to help someone who wanted to take a shot at it.

Hello Brian,

It does sound enticing, my main worry is that I run on an embedded
system with relatively limited RAM resources and I try to avoid
unnecessary overhead wherever I can. Well, the fact that I'm using
python shows that it's not entirely true but that's code I can rewrite
in a future update if I want to save a few MB, the communication
protocol I'll have to stick with for the lifetime of the product so
I'm in a bit of a "premature optimization" mindset.

I've been reading about NORM and while it does seem very nice I only
need a tiny subset of the functionality (effectively UDP RADIO/DISH)
so I'm a bit on the fence about adding such a large dependency just
because ZMQ's UDP sockets don't yet support IPv6.

I think I need to give it a little more thought before I commit either
way but I do appreciate your feedback.

> best regards,
> Brian 
> > On Apr 26, 2018, at 4:55 AM, Lionel Flandrin <lionel at svkt.org> wrote:
> > 
> > On Thu, Apr 26, 2018 at 09:23:13AM +0100, Luca Boccassi wrote:
> >> On Thu, 2018-04-26 at 10:00 +0200, Lionel Flandrin wrote:
> >>> Hello everyone,
> >>> 
> >>> I'm trying to build a multicast protocol on top of an IPv6-only
> >>> network. I found that the draft RADIO/DISH sockets seem to do exactly
> >>> what I want, however the zmq_udp man page doesn't explicitely mention
> >>> supporting IPv6 multicast and I couldn't get pyzmq to bind an IPv6
> >>> multicast DISH with any URL format I've tried.
> >>> 
> >>> Is IPv6 multicast simply currently unsupported for UDP sockets? If
> >>> that's the case is it because of a technical difficulty or simply
> >>> because nobody bothered to implement it?
> >>> 
> >>> Thank you for your help (and your great library),
> >> 
> >> UDP right now supports only ipv4 - it's a work in progress:
> >> https://github.com/zeromq/libzmq/issues/2891
> > 
> > Ah, I see, thank you for confirming that. Do you think adding IPv6
> > support would be a huge amount of work for somebody not familiar with
> > ZMQ's codebase? Is it just about adding a few branches changing
> > AF_INET to AF_INET6 or am I being ridiculously naive?
> > 
> > My current backup solution if I can't get ZMQ to do what I want is to
> > write my own IPv6 multicast code using BSD sockets directly, if
> > hacking ZMQ's code to add support is not too daunting I could consider
> > doing that instead.
> > 
> >> PUB/SUB with PGM or NORM should do what you are looking for.
> > 
> > I considered EPGM briefly but the zmq_pgm man page seems to say that
> > only IPv4 is supported, so I didn't even attempt it:
> > 
> >  A multicast address is specified by an IPv4 multicast address in its
> >  numeric representation.
> > 
> > Maybe I shoudln't have been so quick to dismiss it, I'm going to give
> > it a try. That being said I don't actually need the guarantees of
> > PGM/NORM, in particular I don't care if a frame gets mangled or
> > dropped and I don't need SNDMORE.
> > 
> > Thank you,

Lionel Flandrin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180426/1ab1f474/attachment.sig>

More information about the zeromq-dev mailing list