New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update happy eyeballs for RFC 8305 #762

njsmith opened this Issue Oct 31, 2018 · 2 comments


None yet
3 participants
Copy link

njsmith commented Oct 31, 2018

A new happy eyeballs RFC came out a few months ago:

Golang tracking issue: golang/go#23841

It's interesting. The old one (RFC 6555) was incredibly vague; lots of "well maybe you could do this, or maybe that, there are lots of options ok", then with a paragraph stuck in at the end claiming (incorrectly) to document what browsers actually do. This one has actual concrete recommendations, and apparently corresponds to what MacOS/iOS do. So... anything we should take from it?

They recommend a 250 ms default timeout. Okay, sure, cool. There's some language about adjusting this based on history, within the bounds of 100 ms and 2 s, but I don't think we want to bother tracking history. And, we're not in a great place to do it either – if we were in the kernel or glibc then it would make more sense.

They recommend doing some cleverness with AAAA vs A records during DNS lookup, where if you get a DNS response for your preferred address family first, you should go ahead and start making connections while waiting for the other DNS response. It turns out that you actually can use getaddrinfo to do separate AAAA and A lookups (just specify family=AF_INET6 vs family=AF_INET; in glibc at least this does correctly trigger the appropriate DNS queries, confirmed with wireshark). So in principle we could implement this pretty easily... IF we knew the local host's policy for preferring IPv4 vs IPv6. Which we don't, since it's some operating system level tuning parameter and there's no standard API for accessing it. Sigh. Maybe the new RFC will encourage OSes to implement better APIs here? There's some temptation to hard-code a preference for AAAA, because c'mon it's the future, and that might work fine on consumer devices, but I think this might annoy all the folks still using IPv4-only networks in the datacenter, and that's kind of an important target userbase for trio.

In fact a lot of the fancier recommendations really only make sense when the happy eyeballs algorithm is integrated into the OS. Does anyone know how Apple actually exposes their implementation? Is there some API we should be calling on macOS instead of using our implementation? Or do you have to switch over to some totally different networking API instead of BSD sockets?

It looks like in the short term the only action item here might be to switch our default delay to 250 ms. (I'm sort of tempted to refactor our happy eyeballs implementation a bit while I'm in there, to more closely match the later version I use in the talk, and to track unclosed sockets in a more automated way.)

@Fuyukai Fuyukai added the polish label Nov 4, 2018


This comment has been minimized.

Copy link

joernheissler commented Nov 25, 2018

On my system the default is to return v6 addresses first, then v4. This can be changed in /etc/gai.conf.
When I remove my v6 default route, getaddrinfo will return the v4 address first.

I think you should let getaddrinfo just do what it does.


This comment has been minimized.

Copy link
Member Author

njsmith commented Nov 25, 2018

@joernheissler Yeah, that's what I mean when I complain that we can't do anything clever with DNS lookups because we have no reliable way to figure out whether the OS is configured to prefer IPv4 or IPv6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment