yojimbo
lsquic
Our great sponsors
yojimbo | lsquic | |
---|---|---|
5 | 5 | |
2,379 | 1,449 | |
1.1% | - | |
9.0 | 7.2 | |
25 days ago | about 1 month ago | |
C | C | |
BSD 3-clause "New" or "Revised" License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
yojimbo
-
Multiplayer Networking Solutions
yojimbo/ netcode/ reliable, all developped by Glenn Fidler, author of GafferOnGames
-
"Move all" feature added in inventory. In your face little fudsters. Gaming revolution incoming!
They really just didn't know how to go about building a complex online game or what that entails. At one point they were trying to donate to open source networking projects that were still in development and not production-ready in hopes they'd help them make their game, you'll see them listed as sponsors of yojimbo for example. It was bizarre to watch.
-
Handling acks during 1+ second packet loss with Glenn Fiedler's Reliable UDP Solution
I can't remember exactly how best to handle this (Glenn's yojimbo project is probably your best bet for a concrete implementation), but here's an idea: buffer and ACK some packets (e.g. up to N packets following your missing packet) and discard everything else (without ACK) until the missing one shows up. The protocol will then continuously try to send your missing packet, in addition to the packets you've intentionally not ACK'd. Once the missing packet shows up you can process it and any buffered packets up to your next missing packet and repeat.
-
I need a good and simple networking library for C++
You may want to take a look at yojimbo , looks like it will fit your requirements pretty well.
-
Programming question : Which techniques are used to achieve real-time between players in online openworlds ? (think wow, ff14, teso)
And has his own C++ library for transmitting messages over UDP protocol https://github.com/networkprotocol/yojimbo
lsquic
-
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.
What are some alternatives?
netcode.io - A protocol for secure client/server connections over UDP
msquic - Cross-platform, C implementation of the IETF QUIC protocol, exposed to C, C++, C# and Rust.
ENet-CSharp - Reliable UDP networking library
ssldump - ssldump - (de-facto repository gathering patches around the cyberspace)
KCP - :zap: KCP - A Fast and Reliable ARQ Protocol
starlink-coverage - Calculating some statistics about Starlink satellites
SDLPoP - An open-source port of Prince of Persia, based on the disassembly of the DOS version.
mvfst - An implementation of the QUIC transport protocol.
bitproto - The bit level data interchange format for serializing data structures (long term maintenance).
netty-incubator-codec-quic
SLikeNet - SLikeNet™ is an Open Source/Free Software cross-platform network engine written in C++ and specifially designed for games (and applications which have comparable requirements on a network engine like games) building upon the discontinued RakNet network engine which had more than 13 years of active development.