Unity UNET "Adventure": This is how you do FIFO wrong



  • [was not sure of whether I should post this here, but it's kinda WTF-ey so eh what the hell.]

    So, I'm a diehard fan of the Unity game engine. Absolutely love it.
    But sometimes the Unity team just releases the most bizarre shit.

    Recently, they released 5.1 Release Candidate 1. This release candidate includes their new UNET networking API, which design-wise looks to be a massive improvement over the pile of crap that was Unity Networking previously.

    I develop a plugin for Unity which implements the framework for multiplayer voice chat called DFVoice. So I decided to sit down and come up with an example of how to use DFVoice with UNET.

    About ten minutes later I go to test. Sound is jittery as fuck. "OK" I think to myself. "Must have done something wrong, let's see what it's receiving..."
    All packets in DFVoice have an index attached to them. So I log the sent and received message indices.
    I notice something peculiar with the received messages.

    Received: 1 Received: 0 Received: 5 Received: 4 Received: 3 Received: 2 Received: 10 Received: 9 [...]

    Eh wha? That's not right. No wonder it sounded jittery - DFVoice throws out any packet which is out of order (basically, unreliable sequenced) - as well as informing the codec of the lost packets (for instance, Speex and Opus do some sort of error correction black magic for lost data).
    So it's throwing away 90% of the voice packets.

    After about half an hour of pulling my hair out, I finally tried this:

    public void Start()
    {
        if( NetworkServer.active )
        {
            for( int i = 0; i < 20; i++ )
            {
                RpcTest( i ); // Unity rewrites the IL so that this sends an RPC instead of directly calling the function
            }
        }
    }
    
    [ClientRPC( channel = Channels.DefaultReliable )]
    public void RpcTest( int index )
    {
        Debug.Log( index );
    }
    

    Lo and behold.

    19 18 17 16 15 ... 0

    :wtf:

    So, the messages are buffered and then dispatched... in reverse order, LIFO instead of FIFO.
    I just... how do you mess this up? And let it get to Release Candidate?

    Am I missing something? Is this an easy mistake to make or something?



  • Oh goody. Today they released RC2 with no fixes whatsoever. :rolleyes:



  • I admit I know very little about UNET, but what QOS mode are you using?

    Unity's blog recommends UNETQosType.UnreliableSequenced for voice data.

    Edit: Granted, this blog entry is from like a year ago.



  • UDP may not be reliable, but it still claims to be "best effort". Mangling the packet order like this is not "best effort".

    UDP is doing a better job than Unity here.



  • @henke37 said:

    UDP may not be reliable, but it still claims to be "best effort". Mangling the packet order like this is not "best effort".

    UDP is doing a better job than Unity here.

    Yeah, as it turns out this only affects local clients apparently (when you use the Local Client stuff, it assumes client and server are running in the same application and so it just uses an internal message buffer instead of sending anything over sockets). So the funny thing is that, comparing using a local client connected to the server hosted within the same application instance versus connecting to the server remotely halfway across the planet with Unreliable enabled, the latter situation would almost certainly still be more reliable (at least in terms of message order). And that, to me, seems all kinds of wrong.



  • @powerlord said:

    I admit I know very little about UNET, but what QOS mode are you using?

    Unity's blog recommends UNETQosType.UnreliableSequenced for voice data.

    Edit: Granted, this blog entry is from like a year ago.

    In the above test I used Reliable (although with a local client, Reliable, Unreliable, and UnreliableSequenced are identical in functionality).



  • Well, at least now I know the Unity Team knows about this issue, although for some reason it isn't marked as a known issue. Hopefully gets fixed in RC3, fingers crossed.


Log in to reply