apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maarten Bekers <i...@elexer.com>
Subject Re: [patch] sendfile on win32 slow (bug #20382)
Date Tue, 02 Sep 2003 18:28:57 GMT
hey Bill,

> > Please correct me if i'm wrong, but to my understanding, the
TransmitFile()
> > call is run in overlapped mode, hence transmitfile() returns almost
> > immediatly and only blocks on the WaitForSingleObject() call. Handling
> > timeouts, doesnt work any differently with this than before except that
the
> > blocking in WaitForsingleObject() might take longer than before.
>
> That's precisely the problem.  We need a timeout on WaitForSingleObject to
prevent someone from
> mounting a DoS attack on the server with a client that requests a file
then does not do a receive.
>   The blocksize needs to be no larger than what the slowest client can
receive in 1 timeout period.
> I agree that 64KB is probably way too conservative (ie, assumes
unreasonably slow clients) but
> doubling the blocksize does not really eliminate the problem you are
describing.  I expect there are
> other techniques to do timeouts (with registry settings perhaps?).
But if i interpret the code correctly, a  time-out period to
WaitForSingleobject() is already passed.

To prevent an DoS, perhaps  WaitForSingleObject() could be called in a loop
with, check the value of GetOverLappedResult() for a 'sane' value (this can
be the old MAX_SEGMENT_SIZE), and if the amount of bytes transmitted since
the last call to GetOverlappedResult() is smaller than MAX_SEGMENT_SIZE,
abort the loop and fall out of the sendfile() as the user is not receiving
(quickly) enough.

I did also test with doubling and even quadrupling the blocksize, but the
issue remained unfortunately,

Sincerely,
Maarten Bekers.


Mime
View raw message