On Wed, Apr 13, 2011 at 2:28 PM, William A. Rowe Jr. <[email protected]> wrote: > On 4/13/2011 1:11 PM, Jeff Trawick wrote: >> On Wed, Apr 13, 2011 at 1:51 PM, William A. Rowe Jr. >> <[email protected]> wrote: >>> On 4/13/2011 9:53 AM, Jeff Trawick wrote: >>>> On Tue, Apr 5, 2011 at 9:28 AM, <[email protected]> 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
