I can try and help regarding adding IPv6 to RADIO/DISH UDP protocol. I don't think it should very complicated. I can try and point to you to the places in the code that need to have the support.
On Fri, Apr 27, 2018 at 4:09 PM, Luca Boccassi <luca.bocca...@gmail.com> wrote: > On Fri, 2018-04-27 at 15:00 +0200, Lionel Flandrin wrote: > > On Fri, Apr 27, 2018 at 01:36:13PM +0100, Luca Boccassi wrote: > > > On Fri, 2018-04-27 at 14:29 +0200, Lionel Flandrin wrote: > > > > On Thu, Apr 26, 2018 at 10:58:33AM +0100, Luca Boccassi wrote: > > > > > On Thu, 2018-04-26 at 10:55 +0200, Lionel Flandrin 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. > > > > > > > > > > I'm not too familiar with that module - but it shouldn't be too > > > > > much > > > > > work. Address support is the first thing, and then the right > > > > > socket > > > > > options for V6 multicast in the engine I suppose: > > > > > > > > > > https://github.com/zeromq/libzmq/blob/master/src/udp_address.cp > > > > > p > > > > > https://github.com/zeromq/libzmq/blob/master/src/udp_engine.cpp > > > > > > > > > > Remember to add unit tests as the very first thing. > > > > > > > > I've started doing that and I'm noticing that currently the UDP > > > > addressing code uses inet_addr to parse the IPv4 address instead > > > > of > > > > getaddrinfo like the TCP and PGM code. Is there a reason to avoid > > > > the > > > > additional functionality of getaddrinfo here or can I safely > > > > switch > > > > to > > > > it in the UDP code? Do we want to avoid resolving hostnames here > > > > for > > > > some reason? > > > > > > You can switch, I imagine it was done that way as it was quicker. > > > Remember to add tests. > > > > Got it, thanks. > > > > I've already refactored the existing tests to add IPv6: > > > > https://github.com/simias/libzmq/commit/16834fd4d2dee3460e3c46f44241e > > 73f2a3633f8 > > > > I'm thinking about adding multicast tests as well but I wonder if > > there are some caveats if I try to send and receive multicast traffic > > in the test suite? Am I allowed to subscribe to a random multicast > > address or is it forbidden to genererate external traffic in the > > tests? > > Perhaps add a similar check to the one already present for ipv6 - on > some build systems networking other than loopback might be blocked, so > it would fail the tests. > > -- > Kind regards, > Luca Boccassi > > _______________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > https://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org https://lists.zeromq.org/mailman/listinfo/zeromq-dev
