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

>
>> 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
20KiB.

>> That could also work on all OSes which support the socket option
>> SO_SNDBUF.
>
> 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
Curl_sndbufset-function
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
SO_SNDBUF
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
transfer-
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
that:
Right now I implemented this via the CURLOPT_SOCKOPTFUNCTION function.
However,
some other options (e.g. TCP_NODELAY) have their own option in libCurl.
Has this
any special reason?

Regards,

Christian

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-02-04