Reliable message?

Hi, I just finished the multiplayer manual on the Github but didn't see the reliable message via UDP. Do I have to implement it myself?

 

Alright, it has been said

 

UDP is not reliable by default.
If you want reliability, use TCP. But will cost you bandwidth / latency.

 

A number of UDP based libraries use a reliable overlay on top of UDP, which is still less load than TCP. ENet is one such, and very good too. Look at the benchmarks.

 

Or use C#'s built in TCP sockets / TCPClient. We do this for Mirror/Telepathy too and it works fine.
Why reinvent the wheel, C#'s built in stuff was tested by millions already

 

Thank you, guys! I really like that benchmarks, that's insightful

I'm focusing on fast-paced games so UDP is the best practice, TCP is great in other cases though.

Personally, I had a good time with PhotonServer, but the OnPremise license is way too expensive for hosting authoritative dedicated servers, so maybe next time ENet and Netcode.IO are also on my list, however, I would like to know how far/fast the brand new Unity multiplayer could go first. IMO, it is lacking some important features like reliable/ordered message, but it has the Multiplay (a Unity company) integration which might help a lot when we need to host server on the cloud. So, the biggest problem for me is that their roadmap and ETA of features are unknown.

@vis2k You did a good job! I just stared your repos It's hard to find a MMO framework following the KISS principle. Most of them are just monsters like the KBEngine.

 

I would suggest to watch talks
https://forum.unity.com/threads/connected-games-general-feedback-and-questions.555088/

Specially FPS sample deep dive, (third link I think), where you have explained, how UDP packages are managed, in reliable manner.

 

UDP is not too difficult to implement reliability on top of. I'm frankly surprised the alpha was released without the option.

 

This is probably because, unity is using data package management approach for reliability and checks, discussed on
FPS Sample Game: Networking Deep Dive

 

Yeah I'm just surprised the reliability package isn't ready at this point, even in an alpha form. Most games will need some data sent reliably for certain purposes.

A simple way to implement reliability is to assign a unique tag to all outbound reliable messages and cache them, and when you receive a reliable message you respond with an acknowledgement with that unique tag. When receiving the acknowledgement the original message is removed from the cache, but after a certain time elapses without an acknowledgement the original message is resent. It is a fairly simple process to implement anyone here can probably figure out how to put on top of what they have already put out, but people picking up Unity's networking solution (even in an alpha state) are going to want at least basic features like this turn key ready, otherwise why even use Unity's solution instead of the Socket class?

 

I think they maybe had such feature initially. But I wouldn't be surprised, if they removed it for simplicity, to show what current network system can do. However, weather they will add it I don't know. Certainly wasn't needed for the purpose of presentation.

But I suppose, someone could (or probably will) fork network system and add relevant extensions. This is more likely to happen in my opinion.

But yes I agree, reliability at this stage is easy to implement, from what we got already.

 

Apples and oranges. One is stream-oriented like writing to a file, absolutely unsuitable for games based on time-critical data. Another is message-oriented for fastest possible message delivery. I thought I already explained this.

 

https://gafferongames.com/post/udp_vs_tcp/

 

Hey @nxrighthere thanks for your benchmark! I read all posts on GafferOnGames as well

I want to release a new game within 9 months, but I'm not sure about what Unity is going to implement. Reliable message? Compression? More type support of DataStreamRead/Writer? Reinvent the wheel is not ideal.

 

You don't need to reinvent stuff, everything you need is on GitHub.

 

Is not guranteed, that within 9 months you will get what you require for your game.

You got few options

• One, wait to very last moment, hoping for right feature implemented by Unity.
• Start working on what you require.
• - Then either stick to it
• - Or replace, if Unity utility proves more suitable, if released.
• You can always implement multiplayer post release, in form of major game update.

Either way, make sure, you prepare right hooks for the time, so you can easily transit data in and out, network module.

 

In addition, Unity's transport layer with C# Jobs and ECS is not something exclusive, people in our community already mixed the tech with ENet, I exposed all the required API for this. In the current state, new transport layer under the hood is nothing than just primitive wrapper on top of UDP sockets with a parody of parallelism.

 

Oh, that's GREAT! I thought Jobs/Multi-threading would be a roadblock since I don't know if ENet is thread-safe. I implemented a layered architecture in Entitas before, perhaps I should abstract my network layer as an interface and implement it in ENet first.

 

ENet is not thread-safe in general, but it has several things that can be used across threads/tasks/jobs without any locks and atomic operations (this was achieved by caching and removing shared data from some functions). I'll write about this in the readme on GitHub soon with some explanations to make this clear.

 

Done, hope it helps. If you have any question feel free to drop me a message here or in Discord.

 

OMG you're so kind
I'll try ENet now, just joined your discord, see you there

 

People always send this link around whenever someone mentions those three letters.

People probably sent it to Notch back in 2009. They aren't sending it to him now.

 

I thought your answer would be more mature.

Good luck.

 

Notch utilized TCP because it perfectly fits the concept of continuous world streaming and other data related to it. Back in the days when multiplayer was developed, a good reliable networking library for games simply not existed in Java for such purposes. Creating a custom protocol is not like just wrapping sockets and you ready to go. Players are still using hacks and software trying to reduce lags. This is the reason why the most popular custom servers are utilizing UDP these days. Such games was never a paragon of a good netcode.

 

Is not like TCP and UDP has been invented in minecraft era.
I think this reference may be, from the person, who is relatively young.

These protocols are much, MUCH older, and from back days, no much has changed in theirs principles.
So not sure what the fuss about it is.

Only major factor that has changed, is network bandwidth, and related to it hardware. Hence possibility to to send more data.

 

I've enjoyed watching @vis2k defend TCP when he doesn't even need to. It is simply a protocol with its pros/cons, same with UDP, and seems pretty ideal both for his MMO asset and for beginners to networked gaming to save them some headache getting things working. TCP isn't ideal for every networked game, but there is no reason it would need to be.