Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Update happy eyeballs for RFC 8305 #762
A new happy eyeballs RFC came out a few months ago: https://tools.ietf.org/html/rfc8305
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
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.)