31–40 of 44 posts
I know it's an oft-repeated comment here but it does bear repeating: is it really a good idea to keep writing these libraries dealing with complex untrusted user supplied data in C?
Earlier quoted context omitted.
But lots of the vulnerable C code we have in the world today was written by very experienced C developers, so I don't know that's a particularly strong argument
It is essentially the same as arguing that after huffing paint for 30 years, one is qualified to huff more paint.
I know it's an oft-repeated comment here but it does bear repeating: is it really a good idea to keep writing these libraries dealing with complex untrusted user supplied data in C?
And I love C.
What problem do QUIC and http/3 solve?
a) multiplexed tcp of http/2 is tcp-in-tcp with its well known problems. tcp over udp is not so problematic
b) as a udp protocol, congestion control is user space controlled. There's been some work on congestion control lately, but it's difficult to explore that for client to server transfers with tcp
c) path mtu detection in the presence of icmp blackholes is still a mess, in 2021; a udp based protocol puts control of packtization into userland.
I think that's fairly factual, so here's the opinion part.
a) tcp-in-tcp problems could have been solved by just using tcp. http/2 without multiplexing still gives some benefits (explicit server shutdown indications are a big one for me; binary vs text and compression may help with data length, but framing may not)
b) plugable congestion control would make more sense here to me. A certain company behind quic also controls a widely deployed operating system, and could make it happen; although adoption is slow, so it would take longer than switching to quic for their sites.
c) turning on path mtu blackhole detection by default on that same company's mobile operating system would help here as well. A certain other mobile OS without a diverse hardware marketplace quickly discovers and responds to lost big packets by sending smaller packets.
Earlier quoted context omitted.
Head of line blocking in http/2, and performance/reliability on dodgy mobile connections. It's definitely getting to the point of diminishing returns, but given how widely http is used it does seem to justify the effort.
TCP HOLB is hardly diminishing returns; it’s the defining way in which HTTP/2 is not uniformly superior to HTTP/1.1—because of it, for a meaningful fraction of users, single-connection HTTP/2 behaves visibly worse than its primary competition, up-to-six-connection HTTP/1.1. (Lack of WebSockets support used to be another point, but that got fixed a year or two back.) Some of the other benefits of HTTP/3 over HTTP/2, l…
It's only when you start talking about connections outside a backend network that HTTP2's weaknesses start to show (specifically mobile networks).
I know it's an oft-repeated comment here but it does bear repeating: is it really a good idea to keep writing these libraries dealing with complex untrusted user supplied data in C?
Rust so far does not cover all architectures that C can reach. When the GCC implementation is ready, it might change, but not yet.
Once you get a microcontroller fast enough to handle Http3, you are talking about well known platforms (such as ARM, MIPS, x86). All of which are supported by Rust and LLVM.
https://doc.rust-lang.org/nightly/rustc/platform-support.htm...
What problem do QUIC and http/3 solve?
QUIC requires one less RTT for connection establishment than TCP+TLS, which reduces the time to first byte on new connections.
Besides this QUIC allows the client to migrate between different IP addresses and networks. This means that e.g. a download on a phone doesn't get interrupted if the user moves from cellular to WiFi.
Earlier quoted context omitted.
I guess there is an audience for this stuff, among embedded systems developers or whatever, but after a brief look at the project it doesn't strike me as a project written with the care needed for C libraries. It is severely under-documented, for starters. For example, the word "thread" does not appear anywhere. Not sure why one would choose this over QUICHE.
I had an issue using quiche as a dependency via JNI and it was a blocker (I've moved on). The event would lose its reference and segfault; I was unable to track it to an actual cause in the debugger; lots of time wasted.
I know it's an oft-repeated comment here but it does bear repeating: is it really a good idea to keep writing these libraries dealing with complex untrusted user supplied data in C?
I guess there is an audience for this stuff, among embedded systems developers or whatever, but after a brief look at the project it doesn't strike me as a project written with the care needed for C libraries. It is severely under-documented, for starters. For example, the word "thread" does not appear anywhere. Not sure why one would choose this over QUICHE.
because it doesn't use threads? The library is intended to be used inside an eventloop. I think the same also applies for other typical transport libraries - e.g. HTTP/2 or TLS ones.
> Not sure why one would choose this over QUICHE.
I think there are certainly reasons. lsquic seems a lot more optimized than quiche and most other libraries out there. It makes use of some pretty clever datastructures (e.g. https://github.com/litespeedtech/lsquic/blob/master/src/libl...), and likely has a drastically lower rate of heap allocations than other implementations. Some of those things - like the use of intrusive linked lists - are unfortunately not that easy to apply in Rust.
I wouldn't be suprised if lsquic outperforms various other implementations - and if that's important to users it might be a reason to choose it (but as always: measure for your use-case).
I personally also think Rust is the way to go for system level code. But I wouldn't dismiss a project for not using Rust. And this one at least has a fair set of unit-tests, so it looks to me a lot more sane than a lot of other C based projects.
I bet almost all of the implementations of QUIC right now are open source.