apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@gmail.com>
Subject Re: svn commit: r1089031 - in /apr/apr/trunk: CHANGES network_io/win32/sockets.c
Date Wed, 13 Apr 2011 18:53:28 GMT
On Wed, Apr 13, 2011 at 2:28 PM, William A. Rowe Jr.
<wrowe@rowe-clan.net> wrote:
> 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.

I think the AcceptEx concern is the just path through APR. Please confirm:

WinNT MPM: AcceptEx + GetAcceptExSockaddrs() + apr_os_sock_make()

apr_os_sock_make() still sets remote_addr_unknown in alloc_socket(),
but since WinNT MPM passes in the remote socket address
remote_addr_unknown will be cleared.

(from previous e-mail)

the WinNT AcceptEx breakage was introduced when code was added to set
remote_addr_unknown for all sockets in alloc_socket(); as it was never
cleared, getpeername() would always be called; as getpeername() is
broken on Win2K, havoc ensued

the WinNT AcceptEx breakage was resolved when code was added to clear
remote_addr_unknown if apr_os_sock_make() is called with the remote
addr filled in

View raw message