How does this compare to other rUDP implementations?

[warvstar]

Such as QUIC, KCP, GameNetworkingSockets, ENET, WebRTC datachannels, RakNet?

[TimonPost]

A big question no single small answer. They all have their pros and cons, serve different domains, have different features. The first question you should ask is what is your use case, do you need (reliable/unreliable/ordered/non-ordered packet transfer. What is the data you going to sent, is time important, how big is the data?

• QUIC is an epic protocol, it is not yet stabilized, but if it is it can be a great protocol for gaming purposes. It is stream-based, however, there is a draft for unreliable. Laminar is message-based.
• Game networking sockets is similar to laminar, it uses the principles of gaffer on games, is C++ and is let's say more mature in its features because it's used by Valve. Would be a good choice if you don't mind using C++.
• RakNet is not a protocol it is a whole networking toolkit with servers, clients, protocol, and networking solutions. Remember laminar is a protocol, not a networking toolkit. In my opinion its a terrible code base and outdated, but it is used for gaming solutions. And has been around quite long. It has many great features.
• WebRTC is UDP for web it serves another domain then laminar which is not directly fast-phased-games.

When comparing those protocols you must keep in mind what the domain is that they serve. Laminar for example is build for fast-phased games where there is lots of data, reliability isn't directly needed, and the ordering of packets doesn't always matter. Laminar is build to avoid the congestion of network packets that TCP has. Please read our book for more information about its motivations.

[warvstar]

@TimonPost
Thanks for the explanation! A few of the main things I'm interested in is timing, latency and especially bandwidth (packet overhead). The reason I'm comparing is because I'm writing an RPC library that can choose between a few protocols and want to avoid ones that are obsolete and/or just not competitive. My RTC library will also target the web, so Quic or WebRTC will be one of the ones I add anyway, but just wondering if there would still be a point to add any of the others when targeting a native platform.

As for the RakNet code base, I completely agree that it's a terrible code base, as I had to recently work on a project using it. However I was specifically talking about its rUDP implementation performance and just wondering how it compares in throughput? There have been benchmarks done showing it's faster than ENET with rUDP in a few metrics, such as latency, although I wasn't able to find it just now.

Although I have little doubt Quic, Kcp or this protocol would have trouble competing with it and RakNet is fairly obsolete imo, so I'll probably drop that one off my list.

Also WebRTC has reliable and ordered sending ability, it's packets have an overhead of just under 100 bytes over UDP&IP. It has client and servers for Rust as well, it's not limited to the browser.

Do you have any opinions / comparisons for KCP? It's one of the main ones I'm looking at adding to my RCP library, I'll probably be looking at adding a few different protocols but want to avoid ones that are obsolete or just not competitive.

Thanks for your time!

[TimonPost]

Interesting project! So I am not familiar with KCP, giving it a quick look it looks very interesting (KCP protocol library and provides an additional alternative to RakNet and TCP). Although, is it behind a paywall? That might be a deciding factor. Also, I haven't really worked with ENET. Laminar doesn't have good performance benchmarks that allow you to compare. Probably you would want to write those yourself for the deciding factor on latency and bandwidth. I can not make any assumptions on its speed and bandwidth usage compared to other protocols

Looking at the future potentials of QUIC, I think its a good idea to at least support that one. One downside might be that it heavily relies on futures and async processing. I am not sure how WebRTC reliability performs for fast phases games with lots of traffic. Laminar uses a custom acknowledgment system that assumes there are many packets sent. In this scenario laminar is expected to perform well. So it depends on your expected userbase whether to include it or not. However, since your building an abstraction on top of different protocols it would not directly matter, it can always be implemented later right? Just expose your abstraction and let the user possibly implement their own protocol if needed.

While I love laminar, it does lack developer power those days. However, it might get more attention since bevy experiments with it.