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)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
