Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.2.0.9.2.20030228122453.03c92d90@pop3.rowe-clan.net>
Date: Fri, 28 Feb 2003 12:43:33 -0600
To: dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: PR 15282 AcceptEx problem
In-Reply-To: <3E5E683E.2010900@us.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

This patch can't be applied... it actually introduces a denial of service
problem if folks can simply early-disconnect a server some half dozen
times in a row...  It isn't hard to work up such a tool.

Better; what if we test *which* socket failed.  We are sort of helpless 
when the errors could be either the Listen and Accept socket.  If the
error is on the Listen socket, we should exit signaling the parent to do
a restart with new listeners, if the error is on the accept socket we can
just keep going.

More thoughts inline...

At 01:34 PM 2/27/2003, Allan Edwards wrote:
>As far as I can tell this is a bug in the Sprint
>PCS Connect support for AcceptEx, (they install a
>Winsock transport provider called BMI). However, it slips
>through our checks and causes the accept thread to
>hard loop and consume most of the cpu.

Instead, can we find some patch that will test AcceptEx?  Perhaps we 
create a single local listen and attempt to connect and write to it, test
that the AcceptEx succeeds, and otherwise emit some nasty warnings
and throw a flag that puts us into the Win9x listener code?

>What happens is that in get_listeners_from_parent()
>WSASocket *succeeeds* using the WSAProtocolInfo from
>the parent however, AcceptEx in winnt_accept() fails
>with WSAENOTSOCK.

Does accept() also fail?  Can we use the 9x code to work around these
sorts of problems?

>I don't see what we can do to fix this but we should
>at least avoid hogging the cpu and log an informative
>message. Unless there is a better idea I'll commit to 2.1

I don't as much mind the Sleep(100) or even Sleep(0) so that we
relinquish clock cycles.  It's the arbitrary "foil the server 100 times
and it will exit" problem.

>16327 may be related but I haven't been able to recreate
>the problem with BlackIce or Norton Personal Firewall.

Because those only occur once the listen socket becomes
invalidated, due to DHCP or some other change.  You can trigger
by reconfiguring TCP/IP to switch between two IP addresses.
Again, we can recover gracefully if we ask the parent to do 
a respawn upon recreating all of *it's* listeners.

If the parent can test that the listeners are healthy (with some
simple setsockopt call) then we can just leave it to the child to
exit.  As long as the parent performs a listener health check
before each child process spawn, we should be much better off
than we are today.

Bill