Since the hd^H^Htr iovecs work as expected...
I believe we want to implement the header vecs in terms of a writev call,
followed by a sendfile of the file (with file-length) and trailer vecs.
This will spare us from walking the header vector list for sizes and making
all sorts of asinine adjustments, while reducing it still to two kernel
calls.
Comments?
Bill
Davi Arnaut wrote:
Aaron Bannert wrote:
Hmm, that's not the behavior I am seeing with Leopard's sendfile. I am
seeing the value-result parameter come back with the total byes in the
file plus the total size of the trailers, excluding the headers.
For example, with a header of 80,000 bytes, a file of 200,000 bytes,
and a trailer of 90,029 bytes (from APR's test/sendfile.c test). The
input to the *len param starts as 200,000 (the size of the file) and
after the call it comes back set as 290,029. If you're saying that the
*len return result should be the total bytes sent (headers + file +
trailers) then the result should have been 370,049. Note that in this
example, the other end of the connection appears to have received at
least 119980 bytes.
Could we get a detailed explanation of what all the expected inputs
and outputs are for sendfile in Leopard() (and if it's different that
previous versions, the same for those would help too).
From what I could figure out, it works like this:
o If length <= headers_length: Length output is headers length +
trailers length. No bytes from the file are sent, headers and trailers
are sent.
o If length > headers_length, Length output is headers length + trailers
length + file bytes sent. (length - headers length) bytes from the file
are sent, headers and trailers are sent.
o If length == 0, Length is headers_length + trailers_length + file
size. Everything is sent.
Strange...
Regards,
Davi Arnaut
