Serious issues after updating to 5.6

According to this blog the transport layer was refactored for 5.6. For my project this has recently become the source of a major headache. In version 5.6.2f1 we found that if a client connected from a not-so-great connection (satellite) then we could very easily get in a state where the server was constantly spamming

Code (CSharp):

1. Send Error: NoResources Channel: 1 bytesToSend:<some byte count>
2. no free events for message in the queue

resulting in no one else getting packets. In short, no information was being exchanged. If that particular person with the bad connection disconnected then the server could sometimes recover, but typically everyone had to disconnect for the server to stop spamming and recover. The thing that troubles me most is that Channel 1 is our unreliable channel; in my mind that means that the server should be sending packets and not caring if someone receives them or not - is this incorrect? If that is the case then why is the server getting blocked up with that particular client?

The only posts we could find with similar issues said that increasing Ack from 32 to 128, and increasing the MaxSentMessageQueueSize from 128 to 256 might help. Doing this seemed to have little impact in our tests.

Looking over the patch notes we decided to update to 5.6.2p4 on the off chance that it was related to the unet memory leak. At the same time I doubled the send interval being sent from our network animator from 0.1-->0.2 (effectively cutting our frequent packets in half). This version of Unity now produces a slightly different error after the bad connection client moves a lot

Code (CSharp):

1. SendBytesToReady Failed to <some player>

but still resulting in the same behavior of packets not being sent out.

I would like to stress that this was not occurring for us in builds previous to 5.6 and we made no network settings changes when we migrated (other than those mentioned above to try and resolve the problem). Later this evening I plan on seeing if I can reproduce the issue locally using simulated latency/packet loss; if so I'll attempt to put together a bug report project.

In the mean time is there anything I can do to work around this? I still don't understand how the server is getting backed up on an unreliable channel. This is the first major issue UNET has presented us with and it is a serious blocker for us moving forward. Any thoughts/ideas/etc would be greatly appreciated. I would even be ok with disconnecting the offending user as soon as the queue got backed up but I'm not sure how to go about that for this particular error.

 

Ouch! Do you know if this was fixed in the new versions?
We seriously need to consider this with our planning.

 

We're still on 5.6. I spent some time tweaking our UNET parameters to make things eventually work (although I'm not exactly sure what the cause was). Occasionally one of the clients will crash causing the server to start spewing these messages but it resolves shortly after they disconnect. Here are the settings I am currently using (in json format as it's stored in our DB):

Code (JavaScript):

1. "UnetConfig":{
2.                     "connectionConfig": {
3.                         "PacketSize": 1440,
4.                         "FragmentSize": 500,
5.                         "ResendTimeout": 1200,
6.                         "DisconnectTimeout": 2000,
7.                         "ConnectTimeout": 2000,
8.                         "MinUpdateTimeout": 10,
9.                         "PingTimeout": 500,
10.                         "ReducedPingTimeout": 100,
11.                         "AllCostTimeout": 20,
12.                         "NetworkDropThreshold": 5,
13.                         "OverflowDropThreshold": 5,
14.                         "MaxConnectionAttempt": 10,
15.                         "AckDelay": 33,
16.                         "SendDelay": 10,
17.                         "MaxCombinedReliableMessageSize": 100,
18.                         "MaxCombinedReliableMessageCount": 10,
19.                         "MaxSentMessageQueueSize": 256,
20.                         "AcksType": 4,
21.                         "UsePlatformSpecificProtocols": False,
22.                         "InitialBandwidth": 0,
23.                         "BandwidthPeakFactor": 2.0,
24.                         "WebSocketReceiveBufferMaxSize": 0,
25.                         "UdpSocketReceiveBufferMaxSize": 0,
26.                         "SSLCertFilePath": '',
27.                         "SSLpublicKeyFilePath": '',
28.                         "SSLCAFilePath": ''
29.                     }

 

Great, thank you! I bookmarked your thread.