Am 24.07.2018, 15:04 Uhr, schrieb Daniel Jeliński <djelinski1_at_gmail.com>:

> Could you please run an experiment of your own? If you decide to use
> my code, you need to pick a different URL, I used a server from
> private network that you will not have access to. I'm very interested
> in your findings.

I did run your tests on my own (on Windows 10) and also looked into
Wireshark.
Your findings were correct that SO_SNDBUF is not adjusted automatically
for non-blocking-sockets.

However, your other findings like

> On Windows 2008R2 (and probably on more recent versions as well) the
> system only puts on the wire the amount of bytes it has buffered. This
> is either what is set by SO_SNDBUF (default 8KB) or what was passed to
> send (CURL_MAX_WRITE_SIZE, 16KB), whichever is higher. In case of CURL
> uploads, the system sends 16KB, then waits for acknowledgement from
> the other end before asking the application for the next batch. This
> is readily visible in Wireshark traces.

I can NOT confirm. For me the SO_SNDBUF was 64KiB from beginning on and
worked out well for my test-case. For me the send-ahead (number of
unacknowledged bytes on the wire) was also fine.
In both cases the throughput was similar in my quick tests, but I did not
test it with high bandwidth and high latency, yet.

I still don't think that the SO_SNDBUF is the limiting factor here. Maybe
that's because in my case the SO_SNDBUF is 64KiB by default and this is
enough. I am really surprised that this change give you a significant
improvement in performance. The only thing I can think of is that the
16KiB CURL_MAX_WRITE_SIZE and the 8KiB SO_SNDBUF don't work together very
well.
If somebody else can confirm that your change improves performance I' fine
with your patch.

Maybe somebody else can give their thoughts on this.

Regards,

Christian

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-07-25