hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Johnson <e...@tibco.com>
Subject Re: Buffered output to socket
Date Mon, 21 Apr 2003 16:30:25 GMT
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.

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.

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.

-Eric.

Michael Becke wrote:

> Yes, if this is true (which it appears to be), the lack of buffering 
> could add significant overhead especially when there is high latency.
>
> There are a couple of options for fixing this.  One would be to add a 
> BufferedOutputStream to the HttpConnection.  Though I think this seems 
> the easiest it also raises the questions:
>
>  - when does one flush the stream?
>  - how big should the buffer be to avoid sending the headers in two 
> packets?
>
> Another option would be to just buffer the header content in 
> HttpMethodBase and write it with one HttpConnection.write().  Though 
> this is more manual, it might be a better short term solution as it 
> has few side effects.
>
> Mike
>
> Slavik Markovich wrote:
>
>> The simple reason (as I see it) is performance. Instead of doing 
>> several round trips on the network (send header, receive ack, etc.) 
>> you can send the request in one network frame.
>>
>> I've checked both IE and Mozilla and they both send the request in 
>> one network frame.
>> Hope that makes any sense.
>>
>> Slavik.
>>
>> -----Original Message-----
>> From: Oleg Kalnichevski [mailto:o.kalnichevski@dplanet.ch]
>> Sent: Monday, April 21, 2003 4:24 PM
>> To: Commons HttpClient Project
>> Subject: Re: Buffered output to socket
>>
>>
>> Slavik,
>> What may be the reasons for output buffering other than working around
>> some weird timeout settings?
>> The HttpConnection class can be easily tweaked to perform output
>> buffering. However, I (personally) see no compelling reasons for folding
>> such modifications into the main code tree.
>> The problem can be cleanly solved by turning HttpConnection into an
>> interface, which would allow for extending standard HTTP connection
>> behavior without having to fork HttpClient. Such a radical change cannot
>> take place before 2.0 release, though. It may take a while until we get
>> there. If you are not willing (or can't) simply change your HTTP server
>> settings to something saner, you'll have to maintain your own HttpClient
>> fork
>>
>> Folks, any different opinions on the issue?
>> Oleg  
>>
>>
>> On Mon, 2003-04-21 at 14:57, Slavik Markovich wrote:
>>
>>> Hi all,
>>>
>>> This is probably a known issue (but I haven't found the answer for 
>>> it yet).
>>> I'm using httpclient to post data to a remote server but as far as I 
>>> can see (using ethereal) the client is writing every line to the 
>>> wire without buffering.
>>> After examining the code, I can see that the HttpConnection class is 
>>> using the output stream received from the socket directly.
>>> Is there a reason for the direct writing?
>>> This is a problem for me 'cause the remote server sets a very low 
>>> timeout and returns a bad request response after receiving the 
>>> request line (without any other header line or request body).
>>>
>>> Can I easily add a buffered behavior to the http client?
>>>
>>> 10x
>>>
>>>
>>>
>>> ----------------------------------------------------------------------------------------------------------------
>>> 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
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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