Am 04.02.2013, 14:09 Uhr, schrieb Daniel Stenberg <dan...@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
