hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Becke <be...@u.washington.edu>
Subject Re: Buffered output to socket
Date Sun, 27 Apr 2003 16:28:56 GMT
Good.  I am glad that it worked.  This patch should get added in pretty  
soon.  We are just waiting for the okay from some of the other  
committers before I add it.

Mike

On Sunday, April 27, 2003, at 07:14 AM, Slavik Markovich wrote:

> 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:
>
> http://www.developerweb.net/sock-faq/flatfaq.php#faq22
>
> This seems to apply to our current situation.
>
> Mike
>
> 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.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:  
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:  
> commons-httpclient-dev-help@jakarta.apache.org
>


Mime
View raw message