Re^2: Bidirectional Client/Server - to fork or not to fork?

e of IO::Socket::IP, which can be used as a drop-in replacement for the more outdated IO::Socket::INET class.

Is there a good reason why this is a new module (name) rather than integrated transparently into the IO::Socket::* hierachy?

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^2: Bidirectional Client/Server - to fork or not to fork?

Replies are listed 'Best First'.
Re^3: Bidirectional Client/Server - to fork or not to fork? by Apero (Scribe) on Dec 07, 2015 at 05:11 UTC
My feeling is you'd have to dig into the historical significance of `IO::Socket::INET`, and I don't have much of a personal interest. From what I've read of the IO::Socket::IP class, this is largely not the default for `IO::Socket` PF_INET due to reasons of legacy compatibility (eg: scripts that literally choke if their network socket is not of the exact class `IO::Socket::INET`.) This said, see the docs for `IO::Socket::IP` since you can import it using `use IO::Socket::IP -register` which makes it take over constructor methods when creating either `PF_INET` or `PF_INET6` sockets. This is as close to transparent integration as can be done without possibly breaking older scripts. Perhaps someone else knows more about this history/legacy than I do. Update: also note that as of Perl 5.20, `IO::Socket::IP` is part of Perl's core modules, per the release notes. Presumably this is so that IPv6 sockets work "out of the box" without requiring users of modern Internet sockets to go to CPAN for the replacement.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Bidirectional Client/Server - to fork or not to fork?
by Apero (Scribe) on Dec 07, 2015 at 05:11 UTC

My feeling is you'd have to dig into the historical significance of IO::Socket::INET, and I don't have much of a personal interest. From what I've read of the IO::Socket::IP class, this is largely not the default for IO::Socket PF_INET due to reasons of legacy compatibility (eg: scripts that literally choke if their network socket is not of the exact class IO::Socket::INET.)

This said, see the docs for IO::Socket::IP since you can import it using use IO::Socket::IP -register which makes it take over constructor methods when creating either PF_INET or PF_INET6 sockets. This is as close to transparent integration as can be done without possibly breaking older scripts.

Perhaps someone else knows more about this history/legacy than I do.

Update: also note that as of Perl 5.20, IO::Socket::IP is part of Perl's core modules, per the release notes. Presumably this is so that IPv6 sockets work "out of the box" without requiring users of modern Internet sockets to go to CPAN for the replacement.

[reply]
[d/l]
[select]