cURL / Mailing Lists / curl-library / Single Mail

curl-library

RE: Slow curl uplink https transfers.

From: Cloutier, Joseph \(Joseph\) <jcloutier_at_alcatel-lucent.com>
Date: Thu, 27 Mar 2008 17:54:22 -0500

Dan, I will forward this e-mail to our developers in Poland. Thanks for
the quick response. Will keep you posted on how things turn out. Joe

-----Original Message-----
From: curl-library-bounces_at_cool.haxx.se
[mailto:curl-library-bounces_at_cool.haxx.se]On Behalf Of Daniel Stenberg
Sent: Thursday, March 27, 2008 6:41 PM
To: libcurl development
Subject: Re: Slow curl uplink https transfers.

On Thu, 27 Mar 2008, Cloutier, Joseph (Joseph) wrote:

> We have a slow throughput problem with curl for uplink (from a W2K
sniffer)
> to FTP server problems.
>
> The root cause issue is TCP delayed ACKs. When a packet arrives at
the FTP
> server the server will wait for 200 ms to send out an ACK if another
packet
> is not received.
>
> We can stop this behavior using the TcpAckFrequence setting in the FTP
XP or
> W2K server, but I am worried this might affect other applications
running on
> that server.
>
> Does anyone know of a way to increase curl's buffer size from 0x4000
to, say
> 0xffff? Or is there a way for curl to open up the TCP window?

So libcurl's choice of application level buffer size can cause this flaw
to
trigger? Seems like a blatant flaw in the TCP/IP stack to me. But of
course
that doesn't help at all...

Increasing the buffer size is of course easy but requires a recompile:
change
the CURL_MAX_WRITE_SIZE define in curl/curl.h and recompile.

Chaning the TCP window or any other socket-layer things can be done by
setting
a CURLOPT_SOCKOPTFUNCTION callback and do whatever you deem necessary.

Please let us know if you figure out a combo of these that makes things
run
better!

-- 
  Commercial curl and libcurl Technical Support:
http://haxx.se/curl.html
Received on 2008-03-28