On Tue, Oct 22, 2002 at 10:16:26AM -0400, RBramante_at_on.com wrote:
>
> Go back and see CURLOPT_BUFFERSIZE and set the recv buffer to a smaller
> size if you are concerned with the amount of data the remote is sending.
> If supported by the underlying stack, this will lower the advertised TCP
> window. By advertising a smaller window, you should be automatically rate
> limiting the sender. If you delay your reads, then the recv buffer will
> fill up sooner and the window will drop, causing the sender to backoff, so
> your concerns about excessive buffering, etc. should be unfounded. Rick
> Jones can probably give us a better technical explanation based on his
> excellent response in the "How to set the size of the send buffer" thread,
> but I think this is basically correct in layman's terms.

I see, thanks for the explanation. You mean that, if I don't actually
read the data, then libcurl will say so to the server, am I right ?
It seemed a bit odd to me, as it basically means that, if there is a
long round trip delay between client and server, then the server will
have possibly sent out a load of data before receiving any notification
that the client is full. Unless protocols always wait for a packet ack
before sending a second one ? I thought they didn't. But then I know
pretty much nothing of protocols, so...
Cheers

-- 
Vincent Penquerc'h
-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote