Mirror or MLAPI?

Hi there,
i am currentlly using Mirror, since MLAPI comes out, which one should i pick to use? and One more question, i am finding a voice-chat-tool that can be used in multiplayer-game, i have tried vivox with mirror, but it has many conflicts in code with mirror, is there some solution?

 

I'm curious too - did you learn more since your post?

 

From looking at the documentation MLAPI are waaay behind Mirror in terms of features and stability. I will keep up-to-date with the changes but I don't expect it to be ready for production in 2021.

 

You could ask the Vivox guys to update their Mirror demo.
I talked to them at Unite once and they seemed really friendly and pretty happy about using Mirror

 

MLAPI-a crooked stub of unity developers that was thrown to unity users to shut their mouths about the net code for DOTS that they have been making for many years

 

Except the MLAPI of today is a complete re-write.

Misinformation harms everyone, including the reputation of the person spreading it.

 

Mirror is not a good solution.
It tries to achieve simplicity in the way of less lines of code at the cost of everything. As of today it removed some of the Linq parts but still in the main path of the hottest part of the code which is sending messages, uses reflection to get type name of each message and hash it to a number and ... for every message.

It has been forked from uNet and they made it worse and only fixed a few none-important none-show stopper things like sync list and ... uNet is not supported by unity but neither mirror. If you are not switching to MLAPI for now, I would stick with uNet and its working features which is almost everything. Mirror doesn't solve any of its problems meaningfully. they don't scale it to bigger numbers in real environments and don't seem to know a lot about real network programming based on their technical choices in the codebase and their recommendations.

MLAPI seem to be ok based on a few weeks of tests but I cannot say anything definitive yet.

 

Photon, pun/bolt.
Fusion (another multiplayer solution from photon that does what pun and bolt do, except better)
will release soon, open beta, and if it delivers on what's promised, It'll be the best ready unity integrated multiplayer solution by far.

 

That's like saying water is wet and if it does what it promises, it'll fix your thirst. Networking libraries require time so we'll never know if it delivers until months after it comes out.

 

Here Mirror/MessagePacking.cs at 9fe19bf8e825a6e3029a3312b3d67fba9bdd7650 · vis2k/Mirror (github.com) and it doesn't matter if you later on at least cache this/change it. The fact that you once thought that this is a good idea to call this for every send and many others like 2 threads per client in telepathy and ... means Mirror is not a good solution unless you want to focus on ease of integration with other thigns at the cost of everything else or you want to read a codebase with the smallest possible implementation.

I have nothing personal against you and this is not a personal thing. Just these decisions lead to so much waste which is not acceptable in almost all real situations which you network library matters.

 

To be clear, this calls GetType which si not fast and then FullName which is not fast and gives you a huge string and then hashes it and uses it every time. At minimum it should be cached and I would argue that users for sure should be allowed to use a method with a pre-determined code like the way uNet does it at least for hot paths and you should use it for RPC/State sync and any other high frequency message that you have too.

You made it like this so it is easy to send messages which has other drawbacks like forcing one type per message as well to just remove short numbers and integrate with libs easier. The later is good but there are other ways to achieve it like an editor which allocates codes for libs with names so they could register names and number of codes they need and they ask for them dynamically.

 

Did this actually show up in your profiler?
That's not Linq btw

Mirror uses kcp over UDP now.

When we used TCP, 2 threads per connection was the approach that performed best in Unity.

We have SocketAsyncEventArgs and async/await versions of Telepathy too.
Outside of Unity, they perform significantly better.
Inside Unity, they don't because anything async does not scale in Unity.

So many people got upset about 2 threads per connections. We don't like it either, but we tried every other approach and this one scaled the best in Unity when using managed sockets.

If you have a managed TCP transport that performs better than Telepathy, please do share

 

I said you had linq and now still have things like this. I'm not going to argue with you if this is good or not. of course this is allocating lots of memory and puts presure on GC. And I'm not going to debate on KCP's relevance to a low latency, low overhead game. and of course there is nothing stopping one from creating a x thread work stealing pattern in unity instead of 2 threads per client. It is impossible that an OS changing between say 64 threads performs better than x (where x is number of hyper threads in the core - threads for your IO and other things) theread work stealing from each other.

The fact that async event args was buggy in the mono impl of unity has nothing to do with the number of threads you chose in your implementation and choice of KCP now is irrelevant (KCP is not the best choice either anyways). The fact that your team's leadership thought that Linq and TCP with 2 threads per client were good back then and now think that doing reflection and string manipulation in the hottest path every time is fine and combined with the fact that you never wrote this and just forked mirror and made it worth is enough that nobody should use this unless somebody is using uNet and it suddenly stops working and they want to bring something up quick which mirror is good enough for.

 

Mirror is awsome, keep going mirror!