[Twisted-Python] RFC: IPv6 multicast join/ticket 6597

[Glyph Lefkowitz]

> On Jul 26, 2016, at 11:00 PM, Jason Litzinger <jlitzingerdev at gmail.com> wrote:
> 
>> 
>> Thanks for taking this up!
> No problem, do I need to reflect anything in the Ticket to indicate I'm
> looking at it?

Nothing specific, although any conclusions drawn on the mailing list, or any specific thoughts you have about how you're going to proceed, are always helpful to record on the ticket for future reference.  Even if you think you're going to get it done in the next couple of days, chances are you'll take an 18 month hiatus in the middle and it's always helpful to have those notes to come back to :).

>> 'twisted.internet.udp', as an importable module; not 'udp' as a feature of Twisted (or of the Internet, for that matter).  
> My question was poorly phrased, I assumed that it was the module that
> was problematic, and wondered if anyone was working on an alternative
> where this is better suited.

The module's implementation is actually fine; the only problem is that it's exposed to third-party applications, and that there are some things that those applications can't achieve without it being so exposed.  We need to make it private, but first, we need to address all the issues like this :).

>> We have explicitly avoided adding IPv6 name resolution to the reactor because the reactor's API for name resolution is fundamentally the wrong shape for IPv6.  If you want to add the ability to resolve IPv6 names to the reactor itself, please see this ticket: https://twistedmatrix.com/trac/ticket/4362 <https://twistedmatrix.com/trac/ticket/4362>
>> 
>> For the purposes of this ticket alone, you should probably just skip resolution in _joinAddr1 if resolution is 
> 
> I assume you mean skip resolution in joinGroup as well?  That's the only
> way to avoid resolve completely.

Right, I meant to check isIPv6Address in joinGroup and everything it calls.

> Additionally, any objections to me updating setTTL in this patch?  It's
> pretty common to set the hop limit when doing a multicast.  Not
> required, but common.

Smaller patches are better.  What do you want to 'update' about it?  If it's an independent change, just submit a different ticket and it will probably land quickly if it's an obvious fix.

>> Testing multicast is ... challenging.  I barely have any idea how to set up a test environment for IPv4, and no idea what to do for IPv6.  If you can speak to this in your tests (and hopefully docs as well) that would be super helpful.
>> 
> Indeed.  I have an interest beyond the scope of this change so I'll see
> what I can do/find.

If you have an interest in UDP generally, a fix for this horribly embarrassing and probably pretty important bug <https://twistedmatrix.com/trac/ticket/2790 <https://twistedmatrix.com/trac/ticket/2790>> would be (A) super appreciated, and (B) really straightforward (the ambivalence on the ticket is all about how to test it "realistically", but a straightforward unit test with a fake socket would probably be fine).

Thanks again,

-glyph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20160727/627ead66/attachment-0002.html>