It looks like the #OpenSSL QUIC API might be supported in the coming #ngtcp2 1.12.0 release:
https://github.com/ngtcp2/ngtcp2/pull/1582
This could be exciting for #curl users building with #OpenSSL ...
An #ngtcp2 lead developer told me they have no current plans to adapt to the new #OpenSSL #QUIC API because of its lack of 0RTT support and the "pull model".
Of course someone else can go ahead and write it and ideally someone from #OpenSSL does it, for dogfooding purposes.
I have no heard of any other QUIC stack either having adapted to it yet.
#OpenSSL #QUIC implementation performance is "abysmal" compared to competing solutions such as #ngtcp2 (ngtcp2 is 2-4x faster) and consumes tons (up to 25x in some situations) of memory. (*)
I still don't fathom why the OpenSSL project chose the path they took. It smells heavily of "Not Invented Here" to me.
Surely some future OpenSSL version will fix this mess?
*) https://lists.haxx.se/pipermail/daniel/2025-January/000096.html
Whoa, I just got a basic Python wrapper around ngtcp2 [server only] functional. Lots of error handling and edge cases need to be implemented.
The test that is working is a client (aioquic) connects, opens a stream, both sides send some data, and confirms that the other side received the data.
I really didn't think my last set of changes would make things work, I expected to hit some unimplemented parts.
TODO:
```
$ grep NotImplementedError ngtcp2.py | wc -l
15
```
Well, I can say that ngtcp2 is not coded very defensively. I finally got enough of a framework to call into it, and it causes a segfault.
No error on what possible pointer I messed up, not even an error that I messed up a pointer.