S. Aden wrote:
Correct me if I am wrong but if a client sends 4096 bytes and the
server only reads in 1024 bytes chunks there will be 3072
(4096-1024=3072) bytes left in the server's request input stream. The
remaining 3072 bytes has to be read before the next chunk of data the
client sent will be readable from the servers request input stream.
This is inefficient in that if you really wanted to send data in 4096
byte chunks and read in 4096 byte chunks then you'd have to buffer the
server's request input stream yourself.
My current objective is to send Base64 encoded content I need to send
the content in 4560 byte chunks. The reason for doing this is because
decoding 4560 bytes produces the expected result. Basically I don't
want to buffer the content just to make sure I have right number bytes
before I do a Base64 decode operation.
-Aden
Aden,
There are several layers of code in between the FilePart class's
sendData() method and the internal TCP/IP buffer, many of which
implement their own buffering schemes. The only thing you can be sure of
that you write chunks lesser than 4K in size to *some* output stream.
Beyond that there is *absolutely* no correlation between the size of the
chunks written to that output stream and the size of IP packets sent
across the wire.
Oleg
On 1/19/06, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
S. Aden wrote:
There seems to be quite a lot of magic numbers being used in the HTTP
Client 3.0 code. One that caught my eye in particular is the hard
coded buffer size of 4096 in the FilePart class's sendData() method.
The content of the file stream is read in 4096 byte chunks and then
written to the output stream (socket). I was wondering if there is any
reason for doing this? Perhaps the buffer size should be configurable
property of the FilePart class?
What is the reason one would want to change this value in the first
place? This is just an intermediate read buffer, which should neither be
too small (for performance rreasons) nor too big (for memory footprint
reasons), but otherwise is *completely* irrelevant, because it has no
bearing of what so ever on the internal socket send buffer (SO_SNDBUF)
or IP packet size.
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
