On 10/10/2011 2:22 PM, Eric Covener wrote:
>> Precisely. As we have context->buff allocated for all AcceptFilter
>> schemes, I added the appropriate queries into that buffer in r1181140,
>> and the world seems at peace again for just this short moment.
>
> Trying to fully resolve the 2.3 accptex thread -- Should I add a
> <note> about Win32DisableAcceptEx to mpm_winnt doc? Or even add it
> back in as a "directive" to point to AcceptFilter?
I'm actually giving this further thought... we have three basic modes
right now; acceptex+recycle, acceptex+recycle+data, or accept. Only
the acceptex+recycle+data is new.
In fact, 90% of users observed acceptex problems were -never- with the
acceptex itself. The error occurs in recycling a broken socket handle.
Eliminate socket recycling by default and most problems are going to
go away, whether it is because a network stack component refuses to
properly disconnect a socket and make it ready for recycling, or whether
a previously IPv4 socket turns out to be incapable of handling an IPv6
connection on the next go-around.
So really, we aught to support acceptex and acceptex+data modes without
socket recycling, as well.
My preference would be to treat acceptex as 'none'/default. 'data' means
acceptex+data. 'accept' means accept, rather than acceptex (and it has
no concept of recycling).
Then, add 'recycle', or 'recycle+data', for those who wish to use the
socket recycling feature. I'd advise against it given everything we've
seen over the past 10 years. But if it works as advertised on a user's
particular combination of network stack drivers, then let them keep the
feature if they explicitly enable it. In fact, since Server 2003 (now
that we've killed Server 2000 support)...
if (!DisconnectEx(hSock, NULL, TF_REUSE_SOCKET, 0)
hSock = INVALID_HANDLE;
would let us recycle the non-TransmitFile sockets as well.
On a similar note; non-server flavors of Windows have crippled the entire
TransmitFile API (SendFile enabled) allowing only two simultaneous file
transmissions. I'm thinking of setting SendFile to disabled by default
on any non-server Windows OS in the pre-config phase, and letting the
user enable it explicitly if desired. I don't see a reason to change the
default for windows server OS's.
