SaaSHub helps you find the best software and product alternatives Learn more →
Lsquic Alternatives
Similar projects and alternatives to lsquic
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
NOTE:
The number of mentions on this list indicates mentions on common posts plus user suggested alternatives.
Hence, a higher number means a better lsquic alternative or higher similarity.
lsquic reviews and mentions
Posts with mentions or reviews of lsquic.
We have used some of these posts to build our list of alternatives
and similar projects. The last one was on 2023-04-02.
-
Avoiding HTTP/3 (for a while) as a pragmatic default
I referred to sockets as an API design, not to express an opinion on whether you should place your protocol implementations inside or outside the kernel. (Although that’s undeniably an interesting question that by all rights should have been settled by now, but isn’t.)
Even then, I didn’t mean you should reproduce the Berkeley socket API verbatim (ZeroMQ-style); multiple streams per connection does not sound like a particularly good fit to it (although apparently people have managed to fit SCTP into it[1]?). I only meant that with the current mainstream libraries[2,3,4], establishing a QUIC connection and transmitting bytestreams or datagrams over it seems quite a bit more involved than performing the equivalent TCP actions using sockets.
[1] https://datatracker.ietf.org/doc/html/rfc6458
[2] https://quiche.googlesource.com/quiche
[3] https://github.com/microsoft/msquic
[4] https://github.com/litespeedtech/lsquic
- The Illustrated QUIC Connection
-
LiteSpeed QUIC (LSQUIC) is an open-source implementation of QUIC and HTTP/3
> the word "thread" does not appear anywhere.
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.
-
A note from our sponsor - SaaSHub
www.saashub.com | 26 Apr 2024
Stats
Basic lsquic repo stats
5
1,449
7.2
about 1 month ago
litespeedtech/lsquic is an open source project licensed under MIT License which is an OSI approved license.
The primary programming language of lsquic is C.
Sponsored
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com