You are not logged in.
Pages: 1
For high-performance library such as mORMot, this might be interesting in future :
https://www.chromium.org/quic/
Last edited by AntonE (2022-10-04 16:25:20)
Offline
Implementing QUIC from scratch *correctly* is TOO HARD. I know one open source server-side implementation from M$ (with C API), but this is a big dependency.
In any case, benefits of QUIC is not too big in usual scenarios. Scenarios where it shine is a networks with small bandwidth and bad stability, where HTTP over TCP is too unstable. But IMHO it is better not to get into situations where it may be necessary
Offline
I agree with mpv.
I you want QUIC, e.g. for a web service, then use a QUIC-native front-end server, running as reverse proxy.
QUIC is meant as replacement for HTTP-like resources loading. Not very useful for REST requests.
Some of its advanced features are already implemented e.g. in mORMot WebSockets protocol, like bi-directional communication, request/answer streams, frame gathering or binary headers. The only missing feature is UDP encapsulation, because mORMot WebSockets are regular WebSockets over TCP.
And note that performance won't change much - especially for a REST oriented scenario.
Offline
Pages: 1