httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steffen <>
Subject Re: Using AcceptEx on Windows
Date Sun, 15 Sep 2013 20:49:14 GMT

Current behavior with windows httpd 2.46 is that with AcceptFilter 
that the sever always starts with good traffic.  Most of us dealing 
then with periodic traffic hangs, slow traffic and/or log entries like 
Asynchronous AcceptEx failed. We advise in the info to set with issues 
to  AcceptFilter http none  and AcceptFilter https none.

Falling back to plain or warnings at start up does not help, because 
it starts fine.

It is discussed here and investigate with the AL community, that the 
issue has nothing to do with firewalls, drivers etc.

Maybe an idea to make default none ?  Performance impact is very minor 
or none. There are windows distro's doing so.

On Sunday 15/09/2013 at 22:20, Ivan Zhakov  wrote:
> On Sun, Sep 15, 2013 at 8:04 PM, Jeff Trawick <> 
> wrote:
>> On Sat, Sep 14, 2013 at 3:48 PM, Ivan Zhakov <> 
>> wrote:
>>> On Sat, Sep 14, 2013 at 11:34 PM, Jeff Trawick <> 
>>> wrote:
>>>> On Sat, Sep 14, 2013 at 3:19 PM, Ivan Zhakov <> 
>>>> wrote:
>>>>> On Sat, Sep 14, 2013 at 10:26 PM, Kyle Hamilton <>
>>>>> 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
>>>>>>>> obtained
>>>>>>>> at run time by making a call to the WSAIoctl function with
>>>>>>>> SIO_GET_EXTENSION_FUNCTION_POINTER opcode specified. The
>>>>>>>> buffer
>>>>>>>> passed to the WSAIoctl function must contain WSAID_ACCEPTEX,
>>>>>>>> globally unique identifier (GUID) whose value identifies
>>>>>>>> AcceptEx
>>>>>>>> extension function. On success, the output returned by the
>>>>>>>> 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
>>>>>> 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]
>>>>> --
>>>>> 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?
> I think logging warning message at startup and then fall back to plain
> accept() would be enough for interested admins to check their network
> drivers/VPN/firewalls.
> Performance difference between AcceptEx and accept() relatively small,
> so falling back to plain accept() should not be big problem for most
> setups.
> For example currently we (VisualSVN Server) are forced to configure
> our packaged Apache HTTP Server to disable AcceptEx explicitly to make
> service start on every server. Otherwise we get many support requests
> that service doesn't start.
> --
> Ivan Zhakov

View raw message