hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Slavik Markovich" <Slavik.Markov...@orange.co.il>
Subject RE: Buffered output to socket
Date Sun, 27 Apr 2003 11:14:59 GMT
The patch looks good.
10x guys.
I'm now able to POST to the server without receiving weird timeout errors.
When is it going to be merged into the main CVS branch?

-----Original Message-----
From: Michael Becke [mailto:becke@u.washington.edu]
Sent: Monday, April 21, 2003 7:52 PM
To: Commons HttpClient Project
Subject: Re: Buffered output to socket

Something I found regarding buffering and the Nagle algorithm:


This seems to apply to our current situation.


Michael Becke wrote:
>> It seems to me that wrapping the data to be sent in a 
>> BufferedOutputStream, where the size of the buffer matches the 
>> Socket.getSendBufferSize() might be a good idea.  And then we'd want 
>> to flush the data after we've sent the header of the request, giving 
>> the server the opportunity to fail immediately if it wants to reject 
>> the header (for example, the server could send an unauthorized 
>> response prior to receiving a POST body, supposing that the "100 
>> Continue" logic is not being used by the client).  I've never used the >> getSendBufferSize()
function, though, so I don't know whether it 
>> accurately reflects what the TCP/IP stack is capable of.
> I not sure exactly how the sendBufferSize is used either.  It seems that > the default
value for this buffer on 1.3.1 and 1.4.1 on Windows is 8192 > bytes.  This seems like it
would be more than enough.  The weird thing > is that we do not ever call flush and do
not usually write more than 
> 8192 bytes.  Perhaps there is some kind of wait time before the content > is sent.
 Using this value as a default buffer size seems reasonable. It > would be nice to know
more about it though.
>> Of course, we'd have to be careful, that this doesn't muck with the 
>> "Continue" logic of the EntityEnclosingMethod methods.
>> I'm not sure what side effects there could be, particularly, as the 
>> "contract" for HttpClient simply delivers an OutputStream to the 
>> caller.  There is nothing in the contract that says that the 
>> OutputStream must be a raw socket - in fact, there are many 
>> circumstances in which it cannot be, such as a chunked transfer encoding.
> I agree the contract certainly does not say anthing about buffering.  If > a problem
were to occur because of the buffering we would be right to 
> say "you should flush the buffer".  I do not think that would be very 
> popular though.
>> You're probably right that making a change to buffer all the sends 
>> will likely break something either in our test cases, or for a 
>> client.  On the other hand, forcing a client to call "flush" when they >> mean
to have their data sent to the server can only be good for the 
>> stability of HttpClient clients over the long-term.  Maybe I'm 
>> misjudging the risk, though.
> The long term solution is definitely to move towards buffering I think. >   The questions
is whether or not it's worth it now.  I think we should > give it a try.  If careful, we
should be able to make it transparent to > the user.  Most of the code that will need to
call flush is in the 
> various HttpClient implemented methods.  The only real problem will be 
> with methods implemented by others.
> Mike
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org

To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org

This message contains information that may be confidential or privileged.
If you are not the intended recipient, you may not use, copy or disclose
to anyone any of the information in this message. If you have received
this message and are not the intended recipient, kindly notify the sender
and delete this message from your computer.

View raw message