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.