UNetConnection: implement alternative clamping logic for BandwidthDeltaTime

Development Programming & Scripting Multiplayer & Networking
, ,
1

This question was created in reference to: [UNetConnection: unintended bandwidth [Content removed]

My previous ticket on this topic was closed and the PR declined without explanation, presumably because my proposed fix changed defaul tbehavior and did not offer configurability.

I hereby submit a more conservative PR that does not change default behavior and offers a CVar for configuration: UNetConnection: implement alternative clamping logic for BandwidthDeltaTime by nonemec-havok · Pull Request #14403 · EpicGames/UnrealEngine

Technical details in comments.

[Attachment Removed]

2

Steps to Reproduce

  • choose project that causes heavy network traffic and runs at a real tick rate of e.g. 30Hz
  • set up project with DesiredTickRate at its default MaxTickRate (120 Hz)
  • set up bandwidth trottling to e.g.

[/Script/Engine.Player]

; client-side bandwidth limit in bytes per second

ConfiguredInternetSpeed=100000 ; for internet connection

ConfiguredLanSpeed=100000 ; for LAN connection

[/Script/OnlineSubsystemUtils.IpNetDriver]

; server-side bandwidth limit per client in bytes per second

MaxClientRate=100000 ; for LAN connection

MaxInternetClientRate=100000 ; for internet connection

  • => observe how the bandwidth is throttled not to the configured values but to about 25% (depending on the real tick rate / max tick rate ratio)
    [Attachment Removed]
3

Hi,

Thank you for the revised PR.

The last one was closed for the reasons you stated, as configurability and backwards compatibility were concerns. I do apologize that you did not receive an explanation for the PR being declined though, and I’ll try to ensure that you receive word if there are any concerns with this new change.

It has been received in our internal tracker, and I’ve included a link to this EPS case there. It will be routed to the appropriate subject matter experts for evaluation as soon as possible.

Thanks,

Alex

[Attachment Removed]

4

Excellent - looking forward to hearing the eval result.

[Attachment Removed]

5

I received an email that this support request has been closed - again without any explanation. Please let me know how to deal with this.

[Attachment Removed]

6

Hi,

EPS threads will automatically close after a period of around 2 weeks, but it is possible to reply and reopen a closed thread for a time after that.

While this thread was closed, we still have your PR open in our internal tracker. Unfortunately, other tasks and bug fixes have taken priority, and I cannot provide any estimate as to when the change will be reviewed.

When that happens, someone will reach out here if there are any concerns with the PR. If this thread has been closed permanently by then, they’ll reach out on the PR itself.

Thanks,

Alex

[Attachment Removed]

7

Understood, so I’ll just keep replying when this happens again. No urgency on my side, I just don’t want this to drop off the table again.

[Attachment Removed]

8

Just another reply to keep the issue open until it is actually resolved in some way…

[Attachment Removed]

9

Hi,

Apologies for the late update.

Due to recent internal reorganizing and changes in priority, it’s unfortunately become very unlikely that anyone will be able to review your pull request any time soon.

We’ll keep the pull request and our internal tracker for the PR open, but this thread will be closed. If someone does end up reviewing the change, they’ll reach out on the PR itself if further discussion is needed.

Thanks,

Alex

[Attachment Removed]