httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Stoddard <stodd...@apache.org>
Subject Re: SSL downloads faster than non SSL?
Date Thu, 04 Aug 2005 02:01:17 GMT
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.


Mime
View raw message