koobas.hobune.stream
Any reason why you should not use Legacy Networking system?
So after much turmoil with the lack of documentation on uNet, and now today the matchmaking service CCU limit is bugged for me, I am looking for alternatives. I had a project long ago where I used the (now) legacy networking system. and I feel that the ability to easily just send information back and forth is better for the way I am going to approach doing my networking. (I will be using very few to none positional syncing) And UNet tries to streamline syncing in your face so much that its hard to work around to get what you want to do, done.
TL:DR - Any technical reasons why legacy networking should not be used? Security, lack of support, exc?
I'm worried that the legacy unity networking servers will go offline sometime in the near future, but apparently those servers are open source?
I'd love to know this too. uNet seems very tailored to realtime multiplayer. The Network$$anonymous$$anager seems full of stuff I don't need, and other uNet components (like the Network$$anonymous$$anagerHUD) seem like they should be open source examples, ins$$anonymous$$d of built-in Unity components. It's weird, and feels really disconnected from the rest of Unity.
I would like to know more about this ALSO,
ANY UNITY PEOPLE WATCHING?
What I was trying to do was really complicated, and involved sending raw bytes of my own format. I actually ended up getting it to work with the legacy system, and it still does work. Game here: https://bamboy.itch.io/asteroidians
Though it does occasionally desync still, but I'm pretty sure that's my fault somewhere in the code.
I know from talking to unity staff at Unite Berlin, that they work on yet another network solution based on sockets.
I think it depends on what your setup is. if you're not using any unity services and legacy is working for you, use it. in addition, you could interface it for later ease of swapping it out with another solution.
the most popular and I think will have support for a long time still is Photon.
You have posted such a comment several times now. I'm just wondering what you / they mean by "based on sockets" ^^. UNet, RakNet and pretty much any networking is based on berkeley sockets.
Well, the reasons why you shouldn't use it anymore are:
RakNet (the legacy networking solution) had several connection problems since a player hosting a server behind a NAT router can't be reached directly without special actions from the user (like adding a port forwarding rule in the router). It had support for NAT punchthrough but this only works with some routers since this is actually a hack / exploit. Secure routers wouldn't support NAT punchthrough.
Unity officially disabled their default / development masterserver. This is not a real problem but it shows that they no longer support it.
RakNet is a C++ library which builds on top of the UDP protocol. This makes it impossible to use for WebGL builds and might have more issues on other platforms
RakNet was a nightmare for secure networking and the buffered RPCs were badly implemented since they couldn't be removed selectively. Players who joined after half an hour of gameplay would receive all buffered RPC calls on connect. In general it has a bad support for tracking or controlling lifetime of networked objects. Every player was able to call Network.Destroy on any networked object. So a paradise for cheaters
AFAIK with the latest Unity version (2018.2) the legacy network system is officially deprecated and removed. So it can't be used anymore.
So even when you still use an older Unity version i wouldn't recommend using the legacy networking system.
Keep in mind that the CCU limit only applies to your free usage of the relay server and matchmaking services. When you release your game and want to use those services (which you are not required to use) you usually "go live" where you have to pay for the traffic that your game generates on the Unity servers. When you go live there is no CCU limit anymore. The CCU limit is bound to your Unity editor license. You don't want to release a game that is using your development CCU capacities. Those are meant for testing and developing.
In the beginning there were several issues with the CCU limts not being freed correctly. Though as far as i know those issues have been solved.
Again, just using UNet doesn't require any CCU as long as you ensure your players can connect to each other. For example minecraft doesn't have a matchmaking nor a server browser. Users have to manually connect to a server and users who host a server have to ensure it's reachable from the internet. You can always roll your own matchmaking on one of your own servers.
Thank you very much. This is useful to know. I just wish uNet was more versatile with selecting specific data to send, rather than just pure synchronization. Photon is good, but funds are not.
Uhm UNet is quite versatile. You can use the low level Transport Layer API. Apart from that if you actually want to use the High level API you can define custom network messages which can transmit arbitrary data. The NetworkReader / Writer are similar to BinaryReader / Writers from standard .NET though they even have special packed formats for certain datatypes to decrease the bitcount and has direct support for most Unity value types. You can't really beat the packed formats for int, however if you just want to send raw bytes there are methods to do that as well.
