On Tue, Jan 17, 2012, Daniel Stenberg wrote: > On Fri, 13 Jan 2012, Pierre Ynard wrote: > >One possibility would be to truncate the list of IP addresses to try, > > It would perhaps make sense if we decide that we always spend at > least NNN milliseconds per host name so that if you put say a 5 > seconds timeout on a host name with 100 IP addresses, we still allow > a "sensible" time for each connect attempt. Possibly that "shortest > possible time" would be configurable and could default to something > like 1000 or 2000 milliseconds...
I think it still makes sense without deciding on a minimum time. You could say that libcurl never tries more than 3 (arbitrary) IP addresses. At least you have a guarantee that a timeout no shorter than 1/3 of the configured value will be used, and you can work with that when choosing your timeout settings. However it's true that this approach seems not very flexible and suboptimal. Having a configurable minimum timeout sounds safer. > >An interesting idea would be, instead of equally dividing 2 > >seconds, to for example try the first address for 1 second, then > >if it fails the second one for 500 ms, then the third one for 250 > >ms and then whatever > > Really? If the first connect fails after a given time, is there > really anything at all that would indicate that the next address > would complete the connection in half the time the previous one > didn't succeed on? No. But spreading the range of timeout values used protects against a wider range of failures. This way, if one IP address is down, fallback on the next one still works, and if the host is generally slow, the first IP has a long enough timeout to succeed; whereas dividing the timeout equally makes libcurl resilient only against the former. Regards, -- Pierre Ynard "Une âme dans un corps, c'est comme un dessin sur une feuille de papier." ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
