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 was under the impression that until an overlapped operation COMPLETES, GetOverlappedResult doesn't give us anything useful in return other than ERROR_IO_PENDING. Was I misunderstanding the semantics?
Unfortunately you seem to be right. An early test led me to believe that GetOverlappedResult() reacted as i expected, but this test was apparently very wrong as i am unable to reproduce that behaviour now. I will test more and see if i can find anything that improves performance without introducing this issue. What did strike me as odd is that an quick test resulted in this:
- IIS - 6M/sec - Apache - 0.9M/sec - Apache with SendFile disabled in httpd.conf - 6M/sec
which striked me as odd.
Humm... I need to find my lost MSDN CD and read up on options on TransmitFile(). My guess is that Tf is using some sort of inefficient technique to seek to the file offset. We definitely have som ework to do here.
Bill
Sincerely, Maarten Bekers.
