You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Snapshot Timestamping etc would have to remain consistent, but the general "Are you still with me?/Yes I'm still here" network messages could have a longer delay between each PingPong.
Maybe you don't need to send the PingPongs if you're getting data network messages back and forth since the server would know the client is still there? Only send them periodically and then ramp up if the server thinks the connection is idle or in limbo?
Part of the problem is how Ping/Pong messages evolved. Previously, Ping was only sent by clients every 2 seconds (0.5Hz), and only had client's localTime, which server would return in Pong, and client subtracted that from the current localTime and added that result to ExponentialMovingAverage _rtt.
Now Ping / Pong has been expanded to this and is sent at 10Hz by both server and clients:
Meanwhile, we have TimeSnapshotMessage that has no payload at all, is sent both ways independently at 60Hz, and only serves to trigger an action on the other side (there is no response msg).
I think we should consider the following:
Run the predicted stuff that TimeSnapshotMessage triggers on some sane interval without messages, e.g. 10Hz, and only if there are components in play that actually need that to run
Ping / Pong should be restored to how it was before (client sent only, localTime only, and 0.5Hz)
If we want to keep server aware of each client's RTT, server can calculate that from the Ping msg time difference x 2 without sending its own Ping
Too much bandwidth overhead
Pull the TestPingPong branch
NetworkManager
NetworkTime
NetworkConnectionToClient
NetworkClient
NetworkServer
Setting Up
Remedies
The text was updated successfully, but these errors were encountered: