Buy commercial curl support. 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 Daniel himself.
Re: Network.framework and libcurl
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 27 Aug 2025 10:16:45 +0200 (CEST)
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.
Date: Wed, 27 Aug 2025 10:16:45 +0200 (CEST)
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.htmlReceived on 2025-08-27