I just learned there is a #QUIC in the #Linux kernel effort: https://github.com/lxin/quic
... as a draft PR making curl use it was filed: https://github.com/curl/curl/pull/14313
Support QUIC sockets by moritzbuhl · Pull Request #14313 · curl/curl
Hi, this is still very early as the quic kernel module is still under discussion on the LKML. This is unfinished and needs a lot more modification. I would appreciate some initial feedback now befo...GitHub
This website is tracked using the Matomo analytics tool. If you do not want that your visits are logged in this way you can set a cookie to prevent Matomo / Piwik from tracking further visits of the site (opt-out).
Steven Reed
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to daniel:// stenberg:// • • •Jordan :ms_nonbinary_flag:
in reply to daniel:// stenberg:// • • •somehybrid
in reply to daniel:// stenberg:// • • •Stefan Eissing
in reply to daniel:// stenberg:// • • •LisPi
in reply to daniel:// stenberg:// • • •That sounds mildly sarcastic.
I'm not convinced shoving yet another nontrivial protocol into ambient-authority land is advisable.
daniel:// stenberg://
in reply to LisPi • • •@lispi314 I agree that's worthwhile discussion. There are certainly both pros and cons with both ways: userspace and kernelspace.
I don't think a full QUIC implementation will be accepted into the kernel anytime soon though because of its complexity.
EricJ
in reply to daniel:// stenberg:// • • •I mean... I kind of like it. IPPROTO_QUIC added to ye olde socket API looks neat/simple to me, and (as a transport layer) I think it belongs in the kernel anyway.
I assume you prefer QUIC in userspace? For portability reasons?
daniel:// stenberg://
in reply to EricJ • • •Richard Levitte
in reply to daniel:// stenberg:// • • •My thought: oh, it's finally happening.
I've been expecting this for a while...