-
Notifications
You must be signed in to change notification settings - Fork 24
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
Configuration options for very slow connections (timeout/concurrent downloads) #52
Comments
Hmm... the current strategy is to retry up to 3 times, with read/connect/write timeouts of 10/20/30 seconds for each retry. I think this will still allow for relatively slow connections, as long as a packet is received once every 30 seconds in the worst case. Do you think it should wait longer than that? I'm hesitant to increase the timeouts too much since a hung connection will take a long time to "give up". Maybe it could be a configuration option? (or a GUI prompt if a timeout is reached) |
Hm, if you're using the read timeout and not the call timeout, it should be sufficient as is, tho, it might still be a good idea to bump up the default to 15/30/60 seconds, or perhaps longer if there's parallel downloads. Generally applications normally don't timeout until ~30-60 seconds, up to 5 minutes for more lenient cases, which often are the slow DSL connections that can't really go any faster, although, a connect timeout can be a fail-fast of 5/15/30 seconds with an option to increase it in the case of an even slower connection for any reason. If it still times out then, a GUI prompt to at least retry could be good, along with allowing setting a high or no timeout. |
I've tweaked the retry strategy to be 15/60, which should allow for pretty slow connections while not taking too much longer to carry out all retries if the server is down. It might still be a good idea to have settings to further increase the timeouts, and probably limit the number of concurrent downloads for very slow connections? |
Yeah; concurrent downloads can work for smaller mods (probably about <1MB, tho the new timeout should allow for more now), but for larger ones, those tend to do better as one at a time since they are more likely to just break. Tho, it might also be interesting to look into resuming the download where possible if it still breaks, assuming the server supports it. |
The timeout for downloading large mods (say QSL) is too short for poor connections (<10Mbps downlink).
Increase the timeout to 5-15 minutes, or alternatively, use throughput as a means of measuring whether the connection is alive or not, and trying to resume if the connection dies.
The text was updated successfully, but these errors were encountered: