cURL / Mailing Lists / curl-library / Single Mail


Re: Slow Upload Performance on High-Bandwidth connections on windows

From: Christian Hägele <>
Date: Mon, 04 Feb 2013 15:42:23 +0100

Am 04.02.2013, 14:09 Uhr, schrieb Daniel Stenberg <>:

>> As nobody knows the reason for that workaround exactly I would suggest
>> to make an option to set SO_SNDBUF.
> The problem with that is that nobody would ever know when to set that
> option
> or not. You basically would just have to experience the problem and then
> at
> run-time fairly arbitrarily try the next transfer with the option set. It
> seems like a pretty awful way really...

You are right that this is ugly if you were dependent on that workaround.
However, I believe that not many people are experience these problems. I
don't know when the CURL_MAX_WRITE_SIZE was lowered from 20Kib to 16KiB,
but there is a chance that the problem only occurred with a send size of

>> That could also work on all OSes which support the socket option
> We already have a callback option that allows the application to set
> socket
> options so this can already be done.

I know that callback, but I was thinking about the curl command-line-tool.
I already modified the curl command-line-tool with 2 new parameters
(--sndbuf and --rcvbuf) which uses this callback to set the values.

> The point with the SNDBUF modification libcurl does is that Microsoft
> clearly
> says there's a risk for problems otherwise and it is libcurl's job to
> try to
> act as good as possible to work everywhere in an optimized way.
> But yes, it needs improvements here. I can't think of any better way to
> solve
> this than to detect OS level at run-time and only SNDBUF if <= windows
> 2008,
> so that Vista and later won't get it changed.
>> On all modern OSes this should be the best choice.
> Right. Unless the vendor says it isn't. =)

Okay so there are 2 things to do:

1. Get rid of setting the SO_SNDBUF-option to 16416 via
unless you are running Windows older than Vista.
Personally I would like to get rid of this completely, but I understand
you don't
want to break anything for existing users.

2. Add command-line options for the curl-command-line-tool for setting
and SO_RCVBUF. That would be good because if you are running a OS that
doesn't do
a good job of determine the right buffer-size that options could improve
speed a lot. (e.g. Linux pre 2.6.16)

I already started to write the changes for no 2). I have a question for
Right now I implemented this via the CURLOPT_SOCKOPTFUNCTION function.
some other options (e.g. TCP_NODELAY) have their own option in libCurl.
Has this
any special reason?



List admin:
Received on 2013-02-04