-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Implementing RFC 8305 Happy Eyeballs v2 #2450
Copy link
Copy link
Open
hyperium/hyper-util
#255Labels
A-clientArea: client.Area: client.C-featureCategory: feature. This is adding a new feature.Category: feature. This is adding a new feature.E-mediumEffort: medium. Some knowledge of how hyper internal works would be useful.Effort: medium. Some knowledge of how hyper internal works would be useful.
Metadata
Metadata
Assignees
Labels
A-clientArea: client.Area: client.C-featureCategory: feature. This is adding a new feature.Category: feature. This is adding a new feature.E-mediumEffort: medium. Some knowledge of how hyper internal works would be useful.Effort: medium. Some knowledge of how hyper internal works would be useful.
Hello! I wanted to let you know on Fuchsia we ended up implementing RFC 8305, otherwise known as Happy Eyeballs v2 (see here). The main advantages over RFC 6555 Happy Eyeballs v1 is that v1 can only have a single IPv4 and IPv6 connection requests in flight, but that risks the client stalling out on a black holed address. v2 can have multiple active connections from the same address family to work around this issue.
I'd love to someday upstream it, but I don't currently have the time to figure out how to decouple our implementation from Fuchsia's primitives. The biggest complication is that v2 carries some complex interaction with timers, and our tests leverage the Fuchsia executor's ability to precisely manipulate time to test the various boundary conditions of our implementation. I'm not familiar with tokio/async-std/smol/etc, so I'm not sure if there's a migration process.
I'd be happy to help someone implement the migration in the meantime if someone else needs this functionality.