Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: 8.3.0: test1474 fails every time
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Christian Weisgerber via curl-library <curl-library_at_lists.haxx.se>
Date: Sat, 23 Sep 2023 20:16:42 +0200
Dan Fandrich:
> After much pain I was finally able to install OpenBSD under KVM and reproduce
> this problem. I verified that curl was correctly sending the first 65536 bytes
> of data to the socket in a call to send(2), but the OS reports that only 32716
> bytes were actually sent. The test assumes that the OS will send all 65536
> bytes, so the test fails.
I asked people more knowledgeable about this, and in summary that
test makes assumptions not guaranteed by POSIX. It is inherently
unportable.
As Claudio Jeker <claudio_at_openbsd.org> explains:
So this curl test assumes that it can open a socket and dump 65k of data
into that socket immediatly. There is no contract that allows this.
What they need to do is to setsockopt(s, SOL_SOCKET, SO_SNDBUF, ...) to a
value bigger than 64k (maybe it needs to be around 512k for all the writes
they do). Only after the setsockopt call the send buffer is large enough
to allow for multiple 64k writes.
In linux the socketbuffers are huge and nobody cares. In OpenBSD this is
not the case, we start with a smallish socketbuffer size and slowly scale
it up. Therefor the inital writes take less data until the window is
opened. We do this to preserve kernel memory (the send buffer can't be
reduced once data is committed to it). In general for applications it does
not matter unless someone writes bad tests.
So in the end this regress test is built on assumptions and is
therefor non-portable and prone to fail.
Date: Sat, 23 Sep 2023 20:16:42 +0200
Dan Fandrich:
> After much pain I was finally able to install OpenBSD under KVM and reproduce
> this problem. I verified that curl was correctly sending the first 65536 bytes
> of data to the socket in a call to send(2), but the OS reports that only 32716
> bytes were actually sent. The test assumes that the OS will send all 65536
> bytes, so the test fails.
I asked people more knowledgeable about this, and in summary that
test makes assumptions not guaranteed by POSIX. It is inherently
unportable.
As Claudio Jeker <claudio_at_openbsd.org> explains:
So this curl test assumes that it can open a socket and dump 65k of data
into that socket immediatly. There is no contract that allows this.
What they need to do is to setsockopt(s, SOL_SOCKET, SO_SNDBUF, ...) to a
value bigger than 64k (maybe it needs to be around 512k for all the writes
they do). Only after the setsockopt call the send buffer is large enough
to allow for multiple 64k writes.
In linux the socketbuffers are huge and nobody cares. In OpenBSD this is
not the case, we start with a smallish socketbuffer size and slowly scale
it up. Therefor the inital writes take less data until the window is
opened. We do this to preserve kernel memory (the send buffer can't be
reduced once data is committed to it). In general for applications it does
not matter unless someone writes bad tests.
So in the end this regress test is built on assumptions and is
therefor non-portable and prone to fail.
-- Christian "naddy" Weisgerber naddy_at_mips.inka.de -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2023-09-23