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.
