Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Daniel Kahn Gillmor <dkg <at> fifthhorseman.net>
Subject: Re: [rt.cpan.org #61577] ->sockdomain and ->socktype undefined on newly ->accept'ed sockets
Newsgroups: gmane.comp.lang.perl.perl5.porters
Date: Tuesday 14th February 2012 16:16:36 UTC (over 4 years ago)
On 02/14/2012 10:22 AM, Paul Evans via RT wrote:
> https://rt.cpan.org/Ticket/Display.html?id=61577
>
> 
> I'm a little bit worried about this change.
> 
> In my experience, SO_DOMAIN is far from reliable across platforms. Also, 
> some operating systems omit it entirely but have instead an SO_FAMILY 
> that does the same thing. (I've yet to meet an OS that had both, 
> however).
> 
> I think it's OK to optimistically /try/ to fill in the object slots using

> SO_DOMAIN/FAMILY/TYPE/PROTOCOL, but don't rely on them to necessarily 
> yield an answer.

at the moment, we have scenarios where there is no attempt at all to
yield an answer, and protocol, sockdomain, and socktype just return
undefined.

So the proposed workaround is a significant improvement anyway.

Note that the proposed code to populate the domain parameter cache
doesn't just use SO_DOMAIN; it tries getsockname() first (also
apparently somewhat unportable), and then falls back to trying SO_DOMAIN
if the earlier attempt fails.

If there are platforms on which the proposed fix doesn't work on, i'd be
happy to see patches for those platforms.  but i don't think we should
avoid fixing the platforms which do support these system calls.

	--dkg
 
CD: 134ms