httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kyle Hamilton <>
Subject Re: Using AcceptEx on Windows
Date Sat, 14 Sep 2013 18:26:31 GMT
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
<> wrote:
> Some discussion about it can be found at
> 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]

View raw message