Network.framework and libcurl

Demi Marie Obenour via curl-library <[email protected]> Tue, 26 Aug 2025 14:59:22 -0400
Newsgroups	gmane.comp.web.curl.library
Message-ID	<[email protected]>
On 8/26/25 04:17, Daniel Stenberg wrote:
> On Mon, 25 Aug 2025, Demi Marie Obenour wrote:
> 
>>> I'm not an expert on anything macOS so I might be wrong here, but based on the
>>> past PR for exactly that (https://github.com/curl/curl/pull/17509) it turned
>>> out that we would have to make quite enourmous sacrifices to make curl work
>>> with the Network.framework.
>>
>> VPN On Demand requires using a connect-by-name API.>
> I don't know what that is, but does it work with curl today?

I don't use macOS and don't use a VPN on iOS, so I have no idea.
All of the comments below come from what I have seen in forum
posts and Apple's docs.

>> Is this the problem with that PR, or is it that curl needs an actual socket 
>> file descriptor?
> 
> Some of the many problems with that PR is that it does its own name lookups 
> and does its own connections (because it can't be avoided), meaning that lots 
> of curl options don't work or work differently and that many curl features 
> can't be supported at all. It's just a super weird hack that would be painful 
> to support.
My understanding is that Network.framework has a few parts:

1. A userspace networking stack, which implements TCP, UDP, and everything
   below.  This replaces the kernelspace networking stack used by BSD sockets,
   and has both improved performance and more features.  For instance, it
   supports MPTCP and avoids an extra copy from kernel buffers into user
   buffers.

2. APIs that take a domain name as input and (asynchronously) return a
   connection to it.  This is what is necessary to make VPN On Demand work.
   There is also a deprecated API that can be used to do the same with BSD
   sockets.

3. A TLS implementation based on BoringSSL.  This is usually used with (1)
   and (2), but it can also be used with any other transport (including
   non-TCP transports) via a custom framer.

4. Implementations of QUIC, HTTP/1.x, HTTP/2, and HTTP/3.  These use (1),
   (2), and (3) internally.

At least 1 through 3 can all be used independently of each other.  Using
Network.framework for TLS only requires using (3).  This is orthogonal
to whether libcurl uses Network.framework for TCP/UDP and below, which
is (1).  It is also orthogonal to delegating connection to the OS, which
is (2).

The reason I asked about (1) and (2) is that certain OS features are
only supported if they are used, and have no alternatives in the BSD
socket API.  My understanding is that some of the changes needed for
at least (1) would also be needed to use io_uring on Linux or
registered I/O on Windows, as they don't use socket file descriptors
and are all completion-based APIs.

watchOS has a hard requirement for (1), but I don't think libcurl
makes much sense on it, as Apple requires most apps to use the
high-level URL loading framework there.  I believe this is so that
the entire transfer can happen while the app is suspended, thus
improving battery life.  The transfer is instead done in a separate
process.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

-- 
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html
OpenPGP_0xB288B55FFF9C22C1.asc (application/pgp-keys, 7 KB)
OpenPGP_signature.asc (application/pgp-signature, 833 B)