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 <[email protected]> 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
signature.asc
Description: PGP signature
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
