apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r1089031 - in /apr/apr/trunk: CHANGES network_io/win32/sockets.c
Date Wed, 13 Apr 2011 18:28:05 GMT
On 4/13/2011 1:11 PM, Jeff Trawick wrote:
> On Wed, Apr 13, 2011 at 1:51 PM, William A. Rowe Jr.
> <wrowe@rowe-clan.net> wrote:
>> On 4/13/2011 9:53 AM, Jeff Trawick wrote:
>>> On Tue, Apr 5, 2011 at 9:28 AM,  <trawick@apache.org> wrote:
>>>> Author: trawick
>>>> Date: Tue Apr  5 13:28:59 2011
>>>> New Revision: 1089031
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1089031&view=rev
>>>> Log:
>>>> restructure Windows apr_socket_connect() to more closely match
>>>> the Unix implementation, fixing the getpeername() optimization
>>>> and WSAEISCONN behavior
>>>>
>>>> PR: 48736 (covered WSAISCONN issue)
>>>> Submitted by: <inoue ariel-networks.com> (WSAISCONN handling)
>>>> Reworked/extended by: trawick
>>>
>>> trivia: getpeername() fails for a connected IPv6 socket on XP; this
>>> change to get the getpeername() optimization to work "fixes" that for
>>> the common case
>>
>> Is this another aspect of the same flaw we just worked through, when I last
>> attempted to normalize this?  (That one broke IP addresses on win2k, see
>> for example https://issues.apache.org/bugzilla/show_bug.cgi?id=41693 ).
> 
> That one is hard to follow...  It points to another bug, that one said
> Win32DisableAcceptEX was a work-around, and there's a later update
> from you saying "solved after 2.2.4 for windows 2000".
> 
> I'll look a little further for earlier bug fixes.
> 
>>> I'll probably backport this to 1.4.x for other reasons (but after 1.4.3).
>>
>> So if we tag httpd-2.3-something against 1.4.3, with IPv6 enabled, we will
>> start collecting similar reports to the one above, for XP IPv6 connections?
>>
> 
> In testing 1.4.latest on XP this a.m. I didn't see an issue with my
> simple server app which retrieved local and remote addresses, as the
> getpeername() optimization on that side of the connection is working.
> 
> apr_socket_accept() has this line to let it use the info from accept()
> instead of calling getpeername():     (*new)->remote_addr_unknown = 0;
> 
> With 1.4.latest, the getpeername() optimization on the client side is
> not working, and getpeername() on IPv6 is where the XP bug is.

What I'm suggesting is that AcceptEx fundamentally alters the way that
getpeername() et al will access the socket, sometimes to their detriment.

Make sure you are testing both with and without using AcceptEx.

Mime
View raw message