Bandwidth reduction: enable setting a replication rate per entity?

[cBournhonesque]

Unreal does this with NetUpdateFrequency: https://docs.unrealengine.com/4.27/en-US/InteractiveExperiences/Networking/Actors/ReplicationFlow/

• How to reconcile this with the server's server_update_interval?

[Clonkex]

It's also worth considering the option of bandwidth-limited syncing, like Halo Reach uses. Instead of always syncing every entity, collect all the entities in need of syncing, sort them by some priority value (calculated, for instance, by a priority accumulator + closeness to the camera * some importance value), then start serialising them until you run reach some specified size. For any entities that got serialised, reset the accumulator to 0, for any others, increment the accumulator.

This risks increased mispredictions because dependant entities may be synchronised out of sync and thus the predictions may not always be accurate, but it allows very precise control of bandwidth and is still always moving towards "eventually accurate".

I have no idea if the precise bandwidth control is worth the extra complexity and slightly dodgy predictions but I've always liked the idea. I implemented it in my Godot networking system but I never got further than two capsules moving around so I never got as far as testing how it behaves in a real game.

[cBournhonesque]

Bandwidth-limiting syncing is already implemented :) See this section of the book for more information: https://cbournhonesque.github.io/lightyear/book/concepts/advanced_replication/bandwidth_management.html#prioritizing-replication-groups

It's pretty much exactly what you described:

• you can set a maximum bandwidth
• every ReplicationGroup or Message can get assigned a Priority score (by default 1.0) which gets accumulated
• we serialize groups in order of priority, until the bandwidth limit is reached

Normally it shouldn't increase mispredictions too much, because entities within a ReplicationGroup are always replicated together.

Here is an example showcasing it: https://github.com/cBournhonesque/lightyear/tree/main/examples/priority

I was wondering if on top of that I could update the replication_rate for a given ReplicationGroup, primarily as a way to save on CPU usage. For example for some unimportant background element the replication rate could be 1Hz instead of 10Hz, and the entity wouldn't get included in the priority accumulation most of the time.

[Clonkex]

Aha! Well that'll teach me to comment before I finish reading the docs 🤦‍♂️

[philpax]

I'd also like to express my interest in this, or some variant of it.

I have a game world time (i.e. time of day) that I'd like to synchronise between the server and the client, and that time ticks at a regular rate (i.e. a game-minute every real-second).

I'd like to periodically synchronise the client's time with the server-authoritative time to make sure it doesn't drift too much, and to allow for the server changing the time. I think this would just be running the same system on both the server and the client with prediction, but I'd like to throttle how frequently that update occurs.

Is this currently possible, or will it depend on this issue? Additionally, should I store this in a resource or an entity?

[cBournhonesque]

I think this is already possible; you could either:

• send a TimeUpdate message from server->client at a regular interval, and use that to update a resource on the client
• have 2 Time resources on the server. One is internal, and gets updated regularly. The other is only for syncing to clients (so with server->client replication enabled), and gets updated infrequently via a run_condition. (probably one of these: https://docs.rs/bevy/latest/bevy/time/common_conditions/index.html)

I think this issue is more focused on saving CPU usage by skipping some entities in the replication systems (for which we know we only want infrequent updates)

[cBournhonesque]

I have a use-case (see issue) where we might want to send some messages as soon as possible: when predicting other players, we want to rebroadcast a player's inputs immediately to other players.

This conflicts with the send_interval setting. I wonder if we should just get rid of it altogether, and add a send_interval for each Channel or ReplicationGroup. (or we could leave it, and then the user would be expected to set it to 0.0 if they need to send something every frame, such as client inputs).

So the general flow is:

• are we ready to send, based on the Server's send_interval?
• for each Channel, is the channel's send_timer ready?
• for replication, is the ReplicationGroup's send_timer ready?
• gather all messages and sort them by priority, fit as many as we can given the bandwidth limit. Set their priority to 0.
• Accumulate the priority of all messages. (this part might be tricky. Do we accumulate the priority of all messages? Or only of messages that reached their send_timer? i.e. do we accumulate priority every server send_interval, or every ReplicationGroups send_timer?)

[cBournhonesque]

Enabled sending a send_frequency per replication group here: https://github.com/cBournhonesque/lightyear/pull/465

[cBournhonesque]

The send_interval can now be sent per channel: https://github.com/cBournhonesque/lightyear/pull/466