On 09/06/11 13:07, Alan Buxey wrote:
> hi,
>
> wasnt all this covered in the preface work for HappyEyeballs ?
>
> any client that takes the first DNS answer (as this appears to do)
> is broken - should wait a little longer for an answer for each query
> and then use HE to decide WHICH method to use - fixes the case
> when eg IPv6 address is given but theres no working connectivity
>
> you'd think that web browsers - which all can multithread and deal with
> background transfer and parallel processes/threads - could implement
> this far quicker/better than something thats traditionally a single
> thread/process :-|

For DNS lookups, the client *should* be the system getaddrinfo() 
implementation IMHO. I'm a big hater of applications re-implementing 
that call - there are a lot of crappy programmers out there, and proper, 
consistent getaddrinfo() is really important for eventual IPv6 adoption.

In my ideal world, getaddrinfo() would be an RPC call to a local, 
long-lived recursive resolver, with proper DNS caching semantics.

If that were the case, the flow would look like this:

0.000 app: getaddrinfo(timeout=0.1)
0.001 res: DNS lookups, A & AAAA
0.070 res: DNS reply=A -> into cache
0.100 res: timeout - return to app
0.101 app: getaddrinfo() -> returns A
0.110 res: DNS reply=AAA -> into cache
...
1.000 app: getaddrinfo(timeout=0.1)
1.001 res: cache lookup & return
1.002 app: getaddrinfo() -> returns AAAA,A

That is, a long-lived recursive resolver daemon would still be running 
when the "late" AAAA reply came back, would process & add it the cache, 
and subsequent calls return the full set.

The happy eyeballs RFC hints that connect_by_name() could profitably 
move into such a long-lived daemon, making the "pick lowest RTT" 
decision consistent between different applications on the system.