hyperium / hyperium/hyper

Implementing RFC 8305 Happy Eyeballs v2

Open
#2,450 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

A-client C-feature E-medium
Dominant language
Rust
Stars
16.3k
Forks
1.8k
Avg merge
1d 22h
Merged PRs (30d)
14

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading RFC 8305 and the referenced Fuchsia implementation in src/lib/fuchsia-hyper/src/happy_eyeballs.rs. Compare its Fuchsia primitives and precise-time tests with the runtime options mentioned in the issue, including tokio, async-std, and smol. Done means a runtime-independent Happy Eyeballs v2 implementation with coverage for its timer boundary conditions.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
backend-api-design, networking
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.