Large state update of 13 bytes (Max is 0)

Hi,

I'm getting spammed with this warning. I'm not really sure what to do about it.

It's triggering whatever I'm syncing.

What does it mean?



Thank you.

 

For me, I have 46 bytes per second per client. I can reach 1MB sometimes.

It's the amount of SyncVars you are updating/syncing across the network from server to clients.

I'm still looking for ways to cut down the amount of bytes I'm sending. If anyone knows how to cut down the number of bytes being sent, please share your findings in this thread. Thank you.

 

Even if I sync a variable only once, I get the message. What I understand from this warning is that the maximum of bytes per seconds I can sync is 0... Which doesn't make any sense....

 

I personally try to use the smallest possible primitive types where appropriate.

For example, pretty much all of my enums will be on type 'byte' because you very rarely need an enum with over 256 types.

This article about primitive data type sizes could be quite useful. https://msdn.microsoft.com/en-us/library/ms228360(v=vs.90).aspx

You can save a heck of a lot of data by using smaller data types. For example, sending a byte instead of an int can save you 24 bits every time which adds up and should surely only improve performance (?)

 

key is not to dirty them so much, for example only when necessary delta is reached... Battlefield 4 has by far the best most conservative networking bandwidth I've seen in a modern twitch title. It can pretty much run on a 56k modem.

I'm also very interested in bandwidth saving measures, so tagging this thread.

 

Very interesting, but that doesn't tell me why is the maximum bytes I can sync is 0.

Syncing 1 byte results in a warning telling me I'm trying to sync a large packet, because 1 > 0...

 

Poke around and look to see if you can set the max bytes per seconds to sync with. Usually, this is done automatically by Unity, but I don't know if you can do so manually.

 

I didn't notice the warning before I update to Patch 5.2.2p4.

That might be the problem?

I did, but I didn't find anything.

Thank you

 

Check and compare the difference between the version v5.2.3f1 and the patch version of the change notes. Perhaps a behavioral change?

 

So I've posted this before somewhere, but I'll just share again here some of the approaches I've used. Keep in mind these are general approaches, implementation against whatever networking library you are using will vary. This list isn't really in any order I'm going to just kind of throw some stuff out there.

So one of my main projects is Game Machine, which was designed primarily for large scale pvp combat type games with large numbers of entities in visual range. FYI it's open source and if you dig around you can find implementations for much of what I mention here.

First off, the biggest thing by far is simply don't send data you don't need to send. Basically question every assumption in this area. For instance for a lot of games you don't need to be sending quaternions. I just send a single float representing a heading angle. Local physics takes care of the rest.

After that you have to take a look at bit packing, which is basically finding ways to represent data that take up less space. You generally cannot rely on your networking library to do this. Other then Game machine and Darkrift, I don't know of any solutions that even really try to do bit packing.

Flatbuffers and protocol buffers are the best bet here. Avoid writing your own. You will just create something inferior that is more difficult to work with unless you are some kind of genius.

A lot of what we send over the wire is floats. You don't need the default float precision for networking, at most you usually need just two decimal places. A technique I use here that takes advantage of the protocol buffer int bit packing but will work without it, is to send floats over the wire as integers. Multiply/divide on each end for the conversion.

Use integers for everything you can. Outside of infrequent or say on initial game load, don't use strings. Enums are a great tool here as they translate directly to integers.

A more advanced technique that Game machine uses is it creates a pool of short ids representing player id's. The short id's are integers and the implementation is a queue where unused id's go back into the pool. So the highest short id equals the number of players logged in (or in my case in a specific area of interest grid). The logic gets a bit complex, but basically the first time the server sends player specific information to the client it sends the player id and the short id. After that just the short id. The client can at any time request that the server send the player id on the next update, in case it misses a packet or for whatever reason hasn't been able to map player id -> short id.

The combination of the above lets game machine handle location/movement updates for 50 players in visual range using around 60kbps total bandwidth. That's with a network tick of 20x a second, which is every 50ms which is just below the threshold of 60ms where things start to become visibly noticeable.

The implication of much of the above is that when using Unet, you will need a different approach then the default. If you are making a game that needs more extreme space optimization, say a pvp mmo, then yes you will have to do things differently. My approach would most likely be keep Unet but use protobuf/flatbuffers and use Unet's ability to send byte arrays to send your messages. Basically you keep the good parts of Unet and bypass the others.

But regardless of what networking library you use, thinking about what you are sending and questioning your assumptions will most likely lead you to large improvements in space optimization. Pretty much every technique I use came from looking at what I was sending and asking myself if that was really the best way to express the problem. I would often just back up to a very high level and look at the larger picture, which would often reveal possible different approaches that I wouldn't see if I was just focused on one small area.

 

Thanks for that input, and I'm currently using said method to look at places where I could optimize my syncing variables. The only thing left for me is to find out how my synced variables can get mangled for unknown reasons.

But the OP was looking for ways on increasing the max bytes per second allowed to be sent over the network. For unknown reasons, it was set to 0, and OP would get warnings about large data size, even if the data is just 1 byte large (1 > 0).

 

I'm guessing that's just a poorly worded message that is basically max = total maximum - bytes already sent. So max is how many bytes you can still send out of some maximum that's not stated.

 

When you say mangled, does it actually change the data or just truncate it? Are you trying to send more data in a single packet then the MTU? MTU is normally 1500 bytes max.

 

See thread here for how I can get mangled data.

I could send out 1MB of MTU through multiple packets if I wanted to. I didn't say I sent out 1 MTU packet of 1MB.

 

Additional info : When I run two instances of the game on a Localhost server, the warning doesn't appear.

It's only spamming when using matchmaking.

 

I tryed creating a new project. As simple as possible:

- Added NetworkManager.
- Added NetworkHUD.
- Created Test Multiplayer project on developer.cloud.unity3d.com/multiplayer.
-Called :

Code (CSharp):

1. NetworkManager.singleton.StartMatchMaker();
2.         NetworkManager.singleton.matchMaker.SetProgramAppID((AppID)522351);

on start

- Attached this script to my dummy sphere player :

Code (CSharp):

1. using UnityEngine.Networking;
2.  
3. public class PlayerTest : NetworkBehaviour
4. {
5.  
6.     [SyncVar]
7.     public int intTest = 0;
8.  
9.  
10.  
11.     void Start ()
12.     {
13.         if (isServer)
14.             InvokeRepeating("test", 1f, 1f);
15.     }
16.  
17.  
18.  
19.     [Server]
20.     void test()
21.     {
22.         intTest++;
23.     }
24. }

-Ran 2 instances on 1 computer.

Same thing, the warning appears every second.

 

If you are seeing the issue with a specific unity version only, Then submit it as a bug with this small reproduction that you created. It also might be related to relay server update so check it with another unity version as well if you can.

Cheers

 

same issue. appeared in 5.2.3

 

fps drops too much

 

please fix this problem

 

After doing some detective work I have concluded that the internal static value maxPacketSize of NetworkServer is set to 0 when starting through matchmaking, while it's equal to 1500 on a regular host start. So here's a bit of reflection magic in a custom NetworkManager which resolves the issue.

Code (csharp):

1. using UnityEngine;
2. using UnityEngine.Networking;
3. using System;
4. using System.Reflection;
5.  
6. [AddComponentMenu("Network/NetworkManager")]
7. public class TSNetworkManager : NetworkManager
8. {
9.     public override void OnServerConnect(NetworkConnection conn)
10.     {
11.         base.OnServerConnect(conn);
12.  
13.         Type serverType = typeof(NetworkServer);
14.         FieldInfo info = serverType.GetField("maxPacketSize",
15.             BindingFlags.NonPublic | BindingFlags.Static);
16.         ushort maxPackets = 1500;
17.         info.SetValue(null, maxPackets);
18.     }
19. }

 

What FredrikMyxAkerblom posted fixed the issue with spamming warnings. However, I am still getting this warning for packets larger than 1500. Now I know that that's the MTU, but I'm actually using the ReliableFragmented channel, so the packets should get split into fragments. This doesn't seem to happen though. Any ideas? And by the way, I'm running 5.2.2p1.

 

Just running in to this issue, on 5.3

 

Heard there's 20+ bugfixes for the first upcoming patch release.