On Tue, 26 Aug 2025, Demi Marie Obenour wrote:

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.

In theory this should not have to affect curl in any particular way, but it depends on the specifics. From demos I've seen, Network.framework likes using multiple threads to provide this functionality (I presume since for example timers can get tricky to manage otherwise when done entirely in user space). The impression I've got is that this gets complicated, especially since they seem to like callbacks - from different threads.

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.

We can't use name based API that does all this magic under the hood. Magic that curl needs to own and control itself.

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.

That's basically the only part we would like to access and use but I have not seen anyone work on that or show how that would work.

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

Not terribly interesting for us.

I would like to emphasize that we would not be against anyone implementing network framework support - if and only if it can be done in a clean enough way. It would be welcomed. I have not seen or heard from anyone working on this and I have not seen anyone interested in paying for it to happen either. I'm not holding my breath for it.

--

 / daniel.haxx.se || https://rock-solid.curl.dev
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Reply via email to