 |
 |
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.