I am writing a Minecraft launcher, and I used multi-threading download to accelerate downloading speed.
Here is my implementaion of download itself: gridcore/src/download.rs at 9991b42cf905b4389dad0be24caa277e7837b91a · InfyniteHeap/gridcore · GitHub.
And here is how I use it to reach out multi-threading download: game.rs (github.com)
The issue is that, program will be deadlocked when downloading library files and asset files in the bad network senarios, so I think there must have some bugs in it.
Limited by my capability, I have no idea about how to solve this issue, so I want to ask for help of this.
I don't have any suggestions for the code structure, but your retry loop is dangerous, because it doesn't check what the error is at all, and doesn't wait between retries. For example, if you get a HTTP error 429 Too Many Requests and disregard it by immediately retrying, servers may automatically ban you(r user’s IP address). You should not retry in response to any 4xx status code (because that group means an erroneous request rather than a server failure) except as specified for that particular code.
Retrying without waiting can also be futile; for example, a transient network failure lasting just a second might cause the OS to give you an error immediately on each connection attempt, so that you exhaust your entire maximum count of retry attempts instantaneously, but waiting would let you succeed later.
Unfortunately, I don't have any Rust code or library suggestions for doing this better, but what you've got is potentially worse than not retrying at all.
1 Like
Thanks for your suggestions! I'll take them into my considerations!