Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bandwidth Abuse #3828

Open
MrGadget1024 opened this issue May 20, 2024 · 2 comments
Open

Bandwidth Abuse #3828

MrGadget1024 opened this issue May 20, 2024 · 2 comments
Assignees
Labels
bug Something isn't working

Comments

@MrGadget1024
Copy link
Collaborator

MrGadget1024 commented May 20, 2024

Too much bandwidth overhead

  • We're sending Ping/Pong bidirectionally at 10Hz
    • Hard-coded DefaultPingInterval set to 0.1f
  • We're also sending TimeSnapshot bidirectionally at 60Hz
    • Governed by Network Manager Send Rate

Pull the TestPingPong branch

  • This branch has additional logging added to:
    • NetworkManager
    • NetworkTime
    • NetworkConnectionToClient
    • NetworkClient
    • NetworkServer
  • This branch also has Mirage Profiler added to package manifest.

Setting Up

  • In the Mirror/Tests folder, find TestPingPong folder
  • Open the scene and add to build settings
  • Switch to Dedicated Server platform, Build and Run (IL2CPP)
  • Switch to Desktop platform
  • Open Profiler window and enable Deep Profiling
    • Also add Mirror Received and Mirror Sent modules to profiler
  • Editor Console: enable Collapse
  • Play in editor and connect the client (there is intentionally no Player object)
  • Observe the timestamped log flood in editor and server consoles
  • Observe the bandwidth used in the profiler (400B/s in, 500B/s out)

Remedies

  • Only NT / Prediction needs Snapshot messages, so only enable when they're activated at runtime
    • Does this really need to be 60Hz? Couldn't this be capped at something sufficient, like 30Hz or less?
  • Nothing needs Ping/Pong at 10Hz - Default should be reset back to 0.5Hz or lower as a base keep-alive.

image

image

@MrGadget1024 MrGadget1024 added the bug Something isn't working label May 20, 2024
@SoftwareGuy
Copy link
Contributor

I think the ping/pong stuff can be reduced.

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?

@MrGadget1024
Copy link
Collaborator Author

MrGadget1024 commented May 21, 2024

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:

image

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants