On Sat, Sep 14, 2013 at 3:48 PM, Ivan Zhakov <[email protected]> wrote:
> On Sat, Sep 14, 2013 at 11:34 PM, Jeff Trawick <[email protected]> wrote: > > On Sat, Sep 14, 2013 at 3:19 PM, Ivan Zhakov <[email protected]> wrote: > >> > >> On Sat, Sep 14, 2013 at 10:26 PM, Kyle Hamilton <[email protected]> > wrote: > >> >>> Hi, > >> >>> > >> >>> The mpm_winnt uses AcceptEx API call to accept incoming connections. > >> >>> But MSDN documentation states [1] that consumer should use > WSAIoctl() > >> >>> to get pointer to AcceptEx function instead calling it directly: > >> >>> [[[ > >> >>> Note The function pointer for the AcceptEx function must be > obtained > >> >>> at run time by making a call to the WSAIoctl function with the > >> >>> SIO_GET_EXTENSION_FUNCTION_POINTER opcode specified. The input > buffer > >> >>> passed to the WSAIoctl function must contain WSAID_ACCEPTEX, a > >> >>> globally unique identifier (GUID) whose value identifies the > AcceptEx > >> >>> extension function. On success, the output returned by the WSAIoctl > >> >>> function contains a pointer to the AcceptEx function. The > >> >>> WSAID_ACCEPTEX GUID is defined in the Mswsock.h header file. > >> >>> ]]] > >> >>> > >> >>> Is any reason why WSAIoctl() is not used or just mistake and I > should > >> >>> prepare the patch to fix it?> > >> > Calling WSAIoctl is necessary and useful in certain circumstances to > >> > reduce duplicate work performed on every AcceptEx call (i.e., AcceptEx > >> > calls WSAIoctl on every call, to ensure that the proper implementation > >> > of AcceptEx for the given socket through the proper network provider > >> > is property routed). > >> > > >> > Calling WSAIoctl and using AcceptEx through the pointer returned > >> > bypasses this duplicate work. But, if httpd ever allows a single > >> > instance to be used across multiple network providers (my presumption > >> > is, like IPv4 and IPv6), this duplicate work cannot be avoided, and so > >> > it's easiest and most effective to simply use AcceptEx without the > >> > pointer and let the system figure out how to route it. > >> > > >> > This is digested solely from documentation, and I have done no testing > >> > of the assumptions or validity of the documentation. > >> > > >> I was looking to httpd 2.4.x source code, while trunk code already > >> resolves AcceptEx pointer dynamically using WSAIoctl() since r1363312 > >> [1]. > >> > >> Sorry for noise :( > >> > >> [1] http://svn.apache.org/r1363312 > >> > >> -- > >> Ivan Zhakov > > > > > > I thought this sounded familiar but didn't have a chance to check yet :) > > I'll propose it for backport to 2.4.x. > > > It would be also useful to extended code to automatically fall back to > 'AcceptFilter none' behavior if retrieving AcceptEx entrypoint failed. > It should resolve problems with buggy firewall/VPN software that > doesn't not implement AcceptEx entrypoint. > > -- > Ivan Zhakov > It already tells the admin to try AcceptFilter none on that failure, though I don't know if the feedback is delivered appropriately (does server fail at startup, or does it keep running without accepting connections?). In the short term I'm most interested in making sure the server provides good feedback for failures in this function. I understand the value in automatically falling back to something that will function, for when you want deployment to be as simple as possible, but there is also value in making it abundantly clear to the admin that there is a condition on their system that prevents httpd from running in the highest performing mode. Shrug? -- Born in Roswell... married an alien... http://emptyhammock.com/
