On 04/30/14 00:12, Ted Unangst wrote:
On Tue, Apr 29, 2014 at 10:18, Simon Perreault wrote:
Le 2014-04-29 10:12, Ted Unangst a écrit :
- Run both requests in parallel.
- When one response is received, start a short timer (e.g. 200ms or so).
- If the second response is received before the timer expires, sort and
return the results as usual.
- Otherwise, kill the second request and return what you have.
Yuck. You just added 200ms latency to every connection.
If I'm reading the code correctly, this saves time on average even if we
keep IPv4 as default, and is never worse than the current situation.
getaddrinfo() queries both families in sequence. So you have to wait for
the AAAA request even if the A request finishes quickly. Doesn't matter
which one is first, you have to to wait for both. It makes sense to me
to cap that waiting when the first request yielded results, no matter
which family is the default. Please let me know if my understanding is
wrong.
Good point. I think I was tricked by your proposal into thinking the
current code did something else. Even so, I have a new objection. :)
This will introduce a lot of strange effects based on whether the
second response arrives in time or not. I would not want to debug this.
However, doing the requests in parallel, each geting the same treatment
as if done in sequence (timing out if need be, etc), and then sort them
by the family directive as per resolv.conf could in theory cut the
lookup time in half...
And of course, here's a diff for that:
Oh, crap. The cat ate it. Sorry.
/Alexander
