Well, I don’t like the fact that it utilizes TCP for reliable transmission. It’s not a good way to provide reliability in real-time games for many reasons. Also, I don’t see support for sequencing so the packets may come out of order and it opens the doors to replay attacks. In general, it’s a good library but technically loses in some aspect to the others.
1 Like
Oh yes, very bad :s
Was Enet your best choice right ?
I look for a replacement to Unet LLAPI, with exact same features. Don’t care about HLAPI, I have mine.
For me, technically, ENet is almost a paragon. We improved it in our fork over the past few months (I mentioned here about it). ENet is a time-proven solution that’s used in many successful games like League of Legends for example, and it’s also integrated into the game engines such as Godot, LÖVE, etc.
And strangely enough, ECS is used in LoL for optimisation purposes! Would love to read your thoughts about the new networking in Unity.
Enet and other solutions seems to lack a key feature for me :
Timestamp ?
Or I missed something ?
@hippocoder Well, I have many questions about the new transport layer, and I don’t understand the deprecation of years of work on LLAPI. What technical advantages does it provides (or planned) over the LLAPI and many other available solutions? What the idea behind it, besides the fact that they want to make it an open source project? From my point of view, this is again the reinvention of the wheel, and I’m very skeptical about this decision.
Most people here are not interested in Multiplay/Google services, they just want to work with a solid transport layer paired with a modern high-level API that supports the MonoBehaviour/ECS workflow. People want to build and deploy their own client-server/P2P games. They only need the right tools. Will Unity provide it? Time will tell… As for me, I already made such tools for myself (thanks to @inlife360 and @snacktime ).
@Driiade This is not low-level stuff and that’s why libraries don’t provide it. However, ENet has enet_time_get() or ENet.Library.Time in C# wrapper (it’s monotonic time in our fork), so you can timestamp the packets using this function if you want. The timestamps is not good and efficient way to keep things synchronized, it’s always better to track ticks.
3 Likes
nxrighthere, you said you forked ENet, can you update your benchmark with your fork next to the current Enet so we can compare those results?
Sure, why not. We also performed multiple 24-hour tests, and it works very stably.
oooooooooooo
Hummm, would I have to put your work on my HLAPI, or wait for unity
hmmmmmm.
Really I don’t know ^^’
I re-uploaded the file, forgot to change a few lines of code.
Well if it’s not got a release date, this question doesn’t matter. If there is a release date, do not wait for Unity.
You know, even if they will release it tomorrow, the new transport layer still will be not a bug-free/ready-to-go solution. It will take a lot of time to fix things in a fresh product, and we all know how long it takes for Unity. Do you remember 2014 when LLAPI was introduced? Now they are replacing the tech.
ENet lives about 14 years, it’s designed to work for ages, and we (and many other open source developers) will support it as long as possible.
Yes ENet is old, reliable and so on, but your fork is not I assume, and I’m sure a 14 year old project by itself has a lot of legacy stuff inside and uses old and outdated methods for many things.
Your performance compare looks very promising however.
Is your unity ready C# wrapper on some Github Project and is it supported?
1 Like
We removed the legacy stuff and improved functionality using a modern API (Windows 7 and higher/Linux/MacOS/Mobile platforms).
Nope, it’s available only here and maintained in my local repository at the moment.
I’m always ready to help when I can.
Awesome stuff. Maybe if your willing to throw it on github, that would be awesome.
I’m currently using the LLAPI but it is full with problems so I’m considering switching to another library, Personally I’m a bit scared about putting unmanaged code into my project, but wrapping around enet is ofcourse an option. another is the other librarys, like LiteNetLib.
The big question, what is production ready?
I don’t trust Unity to come up with something decent, that is for sure.
1 Like
It would be nice to have linux (.net core / mono builds) test results.
It will be available on GitHub when I finish converting everything to a safe code. Unsafe code will be optional to keep it as the most efficient way to access and modify data since the networking layer is a performance-critical part and games is latency sensitive applications.
I understand your fears, and that’s why we are performed multiple 24-hour tests to debug unexpected behaviors and to make sure that everything is stable.
We should always be prepared for difficulties, and the real question is how quickly we can solve them. @RevenantX very quickly fixing the bugs in his library, and I believe that LiteNetLib is a reliable choice.
Unfortunately, I can’t provide them at the moment. The source code is open, and you can perform any tests on any target platform yourself.
Just craft your code carefully, make your high-level stuff transport-agnostic as much as possible and you will be able to painlessly replace things when (and if) time will come.
@nxrighthere have you considered measuring latency? It would be interesting to see how TCP based libraries compare to UDP based libs when it comes to latency.
I would also love to see some websocket based protocols, since that is the only thing available for webgl games.
A separate option should be implemented to measure the latency, the application in the current state is not suited for this task. I have many great ideas on my to-do list, but I don’t have time to implement them, unfortunately. Maybe someday, but I can’t promise.