Is there any compression?

[vassembly]

Delta diffs maybe? Or anything else to support huge player counts.

[elementbound]

I don't see delta diffs viable, since state and input properties are sent as unreliable, so at the time we receive a delta, we may or may not have the preceding state to use as reference.

However, an opportunity to reduce data usage is the properties. Currently, the full path of each property is included in the dictionary used to describe state. These names could be replaced with simple indices.

The other thing is channels - currently no channels are specified, the default ones are used. Using specific channels might improve performance.

Created issues for both. Let me know if you have any other ideas or concerns!

[vassembly]

well, delta compression allows you to send diffs of data, that means, you don't have to send relatively big data all the time, but rather, small pieces of it reliably. sorry for the confusion, just making sure we talk about the same thing

[vassembly]

theres a good article by valve about source engine networking. You may find it useful

[elementbound]

Yes, I was aware of the diff part. I didn't consider sending deltas over a reliable channel though!
Do you have any stats on how much traffic this saves? For example, players move around most of the time, so it wouldn't save that much bandwidth. For non-rollback properties, like player health, MultiplayerSynchronizer can be configured to sync only when the value changes.

[elementbound]

Created #173 as a first step for improving netfox in this regard.

[TeTpaAka]

Yes, I was aware of the diff part. I didn't consider sending deltas over a reliable channel though!

I wouldn't recommend sending state data over a reliable channel. The main reason not to use reliable channels is that dropping a single packet delays the arrival of all following packets, which results in noticeable stutter.

I don't see delta diffs viable, since state and input properties are sent as unreliable, so at the time we receive a delta, we may or may not have the preceding state to use as reference.

Fortunately, you don't actually need the preceding state. You just need a preceding state. If the client tells the server which tick it last received, the server can use that tick as reference for the following state diffs.