Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42F176ED.5040704@apache.org>
Date: Wed, 03 Aug 2005 22:01:17 -0400
From: Bill Stoddard <stoddard@apache.org>
Reply-To: stoddard@apache.org
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: SSL downloads faster than non SSL?
References: <42EFDCB9.5010309@cfl.rr.com>
 <92e3673aaf98a7561602cad399ecc5c8@ricilake.net> <42EFEB8E.9000506@cfl.rr.com>
 <6.2.1.2.2.20050803080502.0611d6a0@pop3.rowe-clan.net>
 <42F0E742.2060208@cfl.rr.com>
 <6.2.1.2.2.20050803115813.06689220@pop3.rowe-clan.net>
In-Reply-To: <6.2.1.2.2.20050803115813.06689220@pop3.rowe-clan.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

William A. Rowe, Jr. wrote:
> At 10:48 AM 8/3/2005, Phillip Susi wrote:
> 
>>William A. Rowe, Jr. wrote:
>>
>>
>>>In the APR library, yes, we translate 'apr_sendfile' to TransmitFile()
>>>on win32.  Some other magic occurs to obtain a file handle which can be passed to TransmitFile.  But there are enough flaws in the TF() api
>>>that perhaps this would be better defaulted to 'off'.
>>
>>Really?  Are you quite sure?  I wonder what's hosing it all up.  Once you hand TransmitFile() the socket and file handles, it should blast the file over the network nice and fast. 
> 
> 
> Yes of course :)  However, sadly, Microsoft has a number of bugs 

Search the archives of this or the apr mailing list... other than bugs (which can be reported to MS with 
reasonable expectation that they will be fixed. maybe :-), the most serious flaw is that there is no way to 
timeout calls to TransmitFile.  If I call TransmitFile to send a file and the client chooses to not read any 
of the bytes I send him, transmitfile will fill-up the send buffers in the TCP stack then block forever.  I've 
never found a way to check the 'status' of the call to TransmitFile,  to see if it was making 'acceptable' 
progress sending bytes to the client.

To solve (by some definition of solve) this timeout problem, we made TransmitFile (under apr_sendfile) send no 
more than 64K bytes at a time. The call to transmitfile is non-blocking and the calling thread blocks on 
WaitForSingleObject for 'timeout' seconds. If the call completes before the WaitFor call times out, we send 
the next 64K byte chunk of the file. Repeat until all the file is sent. Whoever came up with the brilliant 
idea of making multiple calls to TransmitFile to send files over 64K bytes needs to be dragged behind a bus ;-)

Now if Apache 2 supported asynchronous (or event driven) writes to the network (like IIS), we could just call 
apr_sendfile/TransmitFile once to send the whole shaboozie and not worry (too much) about whether the client 
is broken or is running a DoS attack.  A monitor thread would periodically check for a transmitfile completion 
status; if the completion status is too slow in coming, the monitor thread cancels the io and closes the socket.