[pacman-dev] Minor issues in lib/libalpm/dload.c
Hi, The following 2 lines has caused me some problems: curl_easy_setopt(curl, CURLOPT_LOW_SPEED_LIMIT, 1024L); curl_easy_setopt(curl, CURLOPT_LOW_SPEED_TIME, 10L); When I bring my laptop at job, I find myself behind a weird corporate router/firewall that throttle down the speed to ~ 1B/sec for the first 10 seconds possibly to reduce bandwidth usage (my personal explanation. People have time to cancel unwanted downloads). This was making my pacman fail to sync any DB. It was just jumping from 1 mirror to another. To fix my problem, I just removed the 2 problematic 2 lines and now everything works like a charm. I share my problem here because I understand that these lines are used to switch to a better mirror in case poor download are caused by the server. I am wondering if I am the only and first user having this problem and how it could be solved cleanly for everyone upstream. Making the option values configurable ? deactivable? ________________________________ CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
On 11.01.2013 00:47, LANGLOIS Olivier PIS -EXT wrote:
Hi,
The following 2 lines has caused me some problems:
curl_easy_setopt(curl, CURLOPT_LOW_SPEED_LIMIT, 1024L); curl_easy_setopt(curl, CURLOPT_LOW_SPEED_TIME, 10L);
[...]
I am wondering if I am the only and first user having this problem and how it could be solved cleanly for everyone upstream.
We could set the limit to 1L then curl would only abort if no data has been transferred so slow connections would still be allowed, but servers no responding wouldn't be much of a problem.
The following 2 lines has caused me some problems:
curl_easy_setopt(curl, CURLOPT_LOW_SPEED_LIMIT, 1024L); curl_easy_setopt(curl, CURLOPT_LOW_SPEED_TIME, 10L);
[...]
I am wondering if I am the only and first user having this problem and how it could be solved cleanly for everyone upstream.
We could set the limit to 1L then curl would only abort if no data has been transferred so slow connections would still be allowed, but servers no responding wouldn't be much of a problem.
I think that it should work. I'll test it on my network and report it back on the list with a patch if it is successful. Thank you, ________________________________ CONFIDENTIALITY : This e-mail and any attachments are confidential and may be privileged. If you are not a named recipient, please notify the sender immediately and do not disclose the contents to another person, use it for any purpose or store or copy the information in any medium.
participants (2)
-
Florian Pritz
-
LANGLOIS Olivier PIS -EXT