EDITED TO ADD: Unfortunately, it turns out that the README file for IO::Socket::INET6 says that it may in a future version lose the ability to talk IPv4. Which would totally kill what I'm doing here, which in turn makes me not want to put it on CPAN. Instead, I'll just point the relevant lines of code here. There's after all only about five of them... 
use IO::Socket::INET;
use IO::Socket::INET6;

BEGIN {
        $::{'IO::'}{'Socket::'}{'INET::'} = $::{'IO::'}{'Socket::'}{'I
+NET6::'}
}

[download]
ORIGINAL POST:

I'm currently involved in one of the few projects in this world that uses real live IPv6. Not much and not exclusively, but some. Apart from a web frontend, the project is written in Perl. Which means that I need to use IPv6 from Perl. This is a less than positive experience.

The basics are there. There are modules that make writing new code that uses IPv6 as easy as it ever gets. The main one, IO::Socket::INET6, is a drop-in replacement for the core IO::Socket::INET. Easy as pie.

The problem is old modules. Since IPv6 support in Perl is implemented by separate modules from CPAN, old code doesn't automatically become v6 aware. If you're lucky, the author of the module has fixed it (Net::DNS is fine, for example). Most of the standard modules are not. libnet isn't. LWP isn't. If you want to fetch stuff from http://ipv6.google.com/ in Perl today, you're out of luck. Hack the module yourself, or call out to wget or curl.

However. Most of the these modules work just fine with IPv6 if you just replace IO::Socket::INET with IO::Socket::INET6. And we can do that after we load the modules, if we're willing to become overly intimate with perl's symbol tables.

Since I don't have time to wait for the modules to get fixed (if the lwp mailing list is anything to go by, that may take years even if I send in patches), I've written a short but evil module that messes with the symbol table for me. It works fine at least for Net::SMTP and LWP::Simple. I call it IPv6::Force at the moment, but that's not a good name.

So, a couple of questions for you lot.

  1. Is there any IPv6 activity going on in the Perl world that I have missed?
  2. What should I call my evil module?
  3. Should I upload it to CPAN?

Replies are listed 'Best First'.
Re: Forcing IPv6 onto existing modules
by moritz (Cardinal) on Dec 17, 2008 at 15:06 UTC
    What should I call my evil module?

    The method of changing methods and packages at run time is called monkey patching, so you could call your module IPv6::MonkeyPatch or IO::Socket::INET6::MonkeyPatch (although I like the former much better).

    Should I upload it to CPAN?

    Yes, please!

[reply]
[d/l]
[select]
Re: Forcing IPv6 onto existing modules
by kyle (Abbot) on Dec 17, 2008 at 16:24 UTC

    I also think that you should upload to CPAN.

    I don't have a suggested name, but I don't like the monkey patching suggestion. Even though I know what "monkey patching" is, I don't think I'd think to look for this kind of thing named that. IPv6::Force actually makes more sense to me. I think putting it under IO::Socket::INET6::... makes sense because IPv6 users would already be aware of IO::Socket::INET6 as a name for IPv6-related stuff.

[reply]
[d/l]

      I agree about not using 'monkey patching' as a component in the name. It's not a term I'd heard before and the fact that Moritz felt the term required further explanation is doubly damning.

      I doubt that creating an IPv6 top level name space is likely to happen, but IO::Socket::INET6::Force is quite compelling - INET6 searches would find it as would IO::Socket related searches.

      Perl's payment curve coincides with its learning curve.
[reply]
Re: Forcing IPv6 onto existing modules
by DStaal (Chaplain) on Dec 17, 2008 at 16:36 UTC

    Upload it. My suggestion is IO::Socket::INET6::Force, but it's not quite right...

    Sounds like the best solution, actually, might be to either merge IO::Socket::INET6 into IO::Socket::INET or just replace the latter with the former entirely if that's an option. (Especially if it's backwards-compatible...)

[reply]
      I think eventually replacing IO::Socket::INET with the code from IO::Socket::INET6 is actually the idea behind the latter. It had to be developed and tested separately, though. Perhaps p5p is the best place to get progress. If the one is considered robust and compatible enough to just take the place of the other, then making it the newer version of the standard module makes sense.
[reply]
      The problem there is that IO::Socket::INET is a core module, so replacing it needs to be done by p5p. I intend to suggest it, but any such change is not going to happen quickly.
[reply]
Re: Forcing IPv6 onto existing modules
by ikegami (Patriarch) on Dec 17, 2008 at 20:09 UTC
    Instead of a new module, maybe it could be an option added to IO::Socket::INET6 
    use IO::Socket::INET6 qw( :force );  # Or whatever

    [download]

    Just an idea.

[reply]
[d/l]
      Interesting suggestion. I'll have a look.
[reply]
        Hi,
        I'm currently preparing a talk about Perl+IPv6 for the next german perl Workshop and I'll implemented this suggestion and took it further.
        To CPAN just uploaded is Net::INET6Glue.
        Part of it makes IO::Socket::INET the same as IO::Socket::INET6 and another part patches IPv6 support into Net::FTP (e.g EPRT, EPSV)
[reply]
Re: Forcing IPv6 onto existing modules
by Tanktalus (Canon) on Dec 17, 2008 at 23:14 UTC

    This just sounds so close to what Module::Replace does that I'm wondering if we couldn't find a way to reuse that module for about the same thing. Perhaps a syntax like: 

    use Module::Replace;
Module::Replace::replace_with('IO::Socket::INET', new => sub {
  my $class = shift;
  $class = 'IO::Socket::INET6' if $class eq 'IO::Socket::INET';
  IO::Socket::INET::SUPER_new($class, @_);
});

    [download]
    (Untested, partly 'cuz Module::Replace doesn't do this yet, but it's sooooo close.)

[reply]
[d/l]

Back to Meditations