I currently don't have a good name for a module I'd like to write,
because I think it is very much required right now.

We have IO::Socket::INET. It wraps PF_INET, thus maknig it IPv4 only.

We have IO::Socket::INET6. It wraps either PF_INET or PF_INET6, despite
its name. It also uses Socket6, thus restricting it to only working on
machines capable of supporting IPv6.

Thus any author wanting to write code to communicate to the internet
(apparently that's some new fad everyone's talking about this week) is
presented a moral dilema: Support IPv6 at the cost of not working on
older v4-only machines, or support older machines but be incapable of
using IPv6.

I originally partially solved this problem some years ago by the
creation of Socket::GetAddrInfo, a module that presents the interface of
RFC2553's getaddrinfo(3) and getnameinfo(3) functions. This however is
not enough for actually connecting and using sockets.

I'd therefore like to propose a new IO::Socket module that uses these
-and only these- functions, for converting between addresses and
name/service pairs.

 use IO::Socket::YourNameHere;

 my $sock = IO::Socket::YourNameHere->new(
    PeerHost    => "www.google.com",
    PeerService => "www",
 );

 printf "Now connected to %s:%s\n", $sock->peerhost, $sock->peerservice;

 ...

Since it would use Socket::GetAddrInfo, it can transparently support
IPv4 or IPv6. Since it would -only- use Socket::GetAddrInfo, it will
work in a v4-only mode on machines incapable of supporting IPv6, and
will not be restricted to only IPv4 or IPv6 if and when some new
addressing family comes along to replace IPv6 one day; as v6 is now
trying to do with v4.

In order to provide an easy transition period, I'd also support
additional IO::Socket::INET options where they still make sense; e.g.
accepting {Local/Peer}Port as a synonym for {Local/Peer}Service. The
upshot here ought to be that you can simply

  sed -i s/IO::Socket::INET/IO::Socket::YourNameHere/

and suddenly your code will JustWork on IPv6 in a good >90% of cases.

Can anyone suggest me a better module name for this?

-- 
Paul "LeoNerd" Evans

leon...@leonerd.org.uk
ICQ# 4135350       |  Registered Linux# 179460
http://www.leonerd.org.uk/

Attachment: signature.asc
Description: Digital signature

Reply via email to