So there’s been a bug where the download keeps resetting in the client, and I got hit with it for this patch cycle, so I decided to investigate to see if I could improve the speed of the download - and it turns out, I can. I do need some specialized software to accomplish the task, though. I think the feature I’m using is available under the free restrictions, but it’s hard to say as I’m still in the trial period.
The software I’m using is NetBalancer, which is something I originally discovered due to frustrations with bad connections with my laptop as I did some traveling. It’s a pretty powerful piece of software, and even allows you to emulate a bad connection by introducing packet drops and adding jitter, so it’s something I’d recommend to software developers for testing how their code works on bad connections.
So I start by creating a rule that limits the speed to 500 KB/s, so I’m still restricting the connection. It does seem like adding jitter or delaying the packets might also work, but it’s a bit harder to guarantee the reset won’t happen.
In order to break the 500 KB/s barrier, I noted that the server allows faster than 500 KB/s for short periods of time, which I can control in NetBalancer: There is a section called “Set the traffic amount condition when this rule becomes active” - and I have it set to apply the rule only when there is more than 5.00 MB Sent & Received in the last 2 seconds. This allows the connection to go faster, but not long enough to trigger resetting the file download.
I’m essentially still limiting the connection to 2.5 MB/s max, but that’s still about 5x faster than straight limiting it to 500 KB/s. Realistically, we’re probably talking 2x or 3x speed, but that’s still a pretty big leap over the abysmally slow 500 KB/s.
If the problem keeps happening in the future, I’ll continue to explore better solutions. Ideally, the devs do need to fix the problem though. It seems to happen as TCP “explores” how much bandwidth is the maximum, and when hits the cap and backs off, MSFS thinks it killed the connection (and is not smart enough to resume in the middle of the download, so starts over). Not sure why the developers make it reset the connection when it’s just TCP engaging in normal behavior; I think they tried to out-think the engineers of the network stack, which is not a great idea.
