You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ivan Zhakov <iv...@visualsvn.com> on 2013/09/11 12:26:44 UTC
Using AcceptEx on Windows
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?
[1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms737524
--
Ivan Zhakov
Re: Using AcceptEx on Windows
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Sun, Sep 15, 2013 at 8:04 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Sat, Sep 14, 2013 at 3:48 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>> On Sat, Sep 14, 2013 at 11:34 PM, Jeff Trawick <tr...@gmail.com> wrote:
>> > On Sat, Sep 14, 2013 at 3:19 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>> >>
>> >> On Sat, Sep 14, 2013 at 10:26 PM, Kyle Hamilton <ky...@kyanha.net>
>> >> 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?
>
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
Re: Using AcceptEx on Windows
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Sep 14, 2013 at 3:48 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Sat, Sep 14, 2013 at 11:34 PM, Jeff Trawick <tr...@gmail.com> wrote:
> > On Sat, Sep 14, 2013 at 3:19 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> >>
> >> On Sat, Sep 14, 2013 at 10:26 PM, Kyle Hamilton <ky...@kyanha.net>
> 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/
Re: Using AcceptEx on Windows
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Sat, Sep 14, 2013 at 11:34 PM, Jeff Trawick <tr...@gmail.com> wrote:
> On Sat, Sep 14, 2013 at 3:19 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
>>
>> On Sat, Sep 14, 2013 at 10:26 PM, Kyle Hamilton <ky...@kyanha.net> 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
Re: Using AcceptEx on Windows
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Sep 14, 2013 at 3:19 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> On Sat, Sep 14, 2013 at 10:26 PM, Kyle Hamilton <ky...@kyanha.net> 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.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: Using AcceptEx on Windows
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Sat, Sep 14, 2013 at 10:26 PM, Kyle Hamilton <ky...@kyanha.net> 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
Re: Using AcceptEx on Windows
Posted by Kyle Hamilton <ky...@kyanha.net>.
tl;dr version:
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.
-Kyle H
On Wed, Sep 11, 2013 at 1:52 PM, Marion & Christophe JAILLET
<ch...@wanadoo.fr> wrote:
> Some discussion about it can be found at
> http://stackoverflow.com/questions/4470645/acceptex-without-wsaioctl
>
> CJ
>
>
> Le 11/09/2013 12:26, Ivan Zhakov a écrit :
>
>> 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?
>>
>> [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms737524
>>
>
Re: Using AcceptEx on Windows
Posted by Marion & Christophe JAILLET <ch...@wanadoo.fr>.
Some discussion about it can be found at
http://stackoverflow.com/questions/4470645/acceptex-without-wsaioctl
CJ
Le 11/09/2013 12:26, Ivan Zhakov a écrit :
> 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?
>
> [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms737524
>