Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: softfail (asf.osuosl.org: transitioning domain of
 psusi@cfl.rr.com does not designate 209.208.122.204 as permitted sender)
Message-ID: <4329E1A6.3060806@cfl.rr.com>
Date: Thu, 15 Sep 2005 17:03:34 -0400
From: Phillip Susi <psusi@cfl.rr.com>
User-Agent: Mozilla Thunderbird 1.0+ (Windows/20050330)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: Bandwidth Limit on Windows
References: <4329B5D8.30409@Ivn.cl> <4329B7FB.1080108@cfl.rr.com>
 <4329C11D.5030805@rowe-clan.net> <4329C72A.6010209@cfl.rr.com>
 <4329CB88.4030003@rowe-clan.net>
In-Reply-To: <4329CB88.4030003@rowe-clan.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

William A. Rowe, Jr. wrote:
> 
> It's called swap-death.  Forcing the system to begin paging both mapped
> files (which aren't swapped to the swap file since their contents are
> unchanged, e.g. your programs and dll files' code pages) and ram (which
> is thrown at the swap file) slows it down considerably.
> 
> Bill
> 

This is not true.  Mapping a full view of a large file does not cause 
any data to actually be read, and hence, any memory to be used.  Data is 
only read from disk as the pages are faulted in on access.

William A. Rowe, Jr. wrote:
 >
 > Yup.  It's definately worth considering your alternatives.  It's also
 > worth looking at what socket-level timeouts exist, or if we can start
 > plugging in some higher-level timeout within the MPM.  When a process
 > does nothing in certain phases of the request cycle after some timeout,
 > simply close the socket from underneath APR.
 >
 > So how to figure out if we are making progress?  I'm unsure and this
 > all deserves another look at the current state of the Win32 sockets API,
 > I haven't fallen down that well in a good long time :)
 >
 > Of course async would be wonderful, at some point, as apache 3.0 starts
 > to draw interest.
 >
 > Bill
 >

I agree, trying to solve this kind of DoS attack in the httpd is kind of 
futile.  Also async IO is the way to go imho, and I've been spending 
some spare time lately trying to figure out how hard it would be to 
modify apache to take advantage of async IO, which would allow for the 
kind of zero copy IO that sendfile and TransmitFile were created for, 
without the problems they cause.  It also allows a small number of 
threads to scale to serving a very large number of clients.