Skip to content
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.

Sign up for GitHub

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

roadmap: rewrite the section about efficient handshakes #461

Merged
merged 2 commits into from
Oct 12, 2022
Merged

roadmap: rewrite the section about efficient handshakes #461

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
1379c5c
roadmap: rewrite the section about efficient handshakes
marten-seemann Sep 28, 2022
5c2f4c0
fix typos
marten-seemann Oct 4, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 10 additions & 12 deletions ROADMAP.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -322,21 +322,19 @@ be achieved with the [WebTransport](#✈️-webtransport) protocol.
**High priority for: IPFS**

**What?** Establishing a connection and performing the initial handshake
should be as cheap and fast as possible. Supporting things like
*selective* stream opening, *preemption*, *speculative* negotiation,
*upfront* negotiation, protocol table *pinning*, etc. may enable us to
achieve lower latencies when establishing connections, and even the
0-RTT holy grail in some cases. These features are being discussed in
the *Protocol Select* protocol design.

**Why?** Multistream 1.0 is chatty and naïve. Streams are essential to
libp2p, and negotiating them is currently inefficient in a number of
scenarios. Also, bootstrapping a multiplexed connection is currently
guesswork (we test protocols one by one, incurring in significant
ping-pong).
should be as cheap and fast as possible. On TCP, The current libp2p
handshakes spends one round-trip negotiating the security protocol, and
another roundtrip negotiating the stream multiplexer.
By using advanced features of the handshake protocol, we might even be
able to reach the holy grail of a 0-RTT handshake in some cases.

**Why?** Applications rely on quick connection establishment. libp2p
shouldn't make them wait for any longer than absolutely necessary.

**Links:**

- [security protocol in multiaddr](https://github.com/libp2p/specs/pull/353)
- [muxer selection in security handshake](https://github.com/libp2p/specs/pull/446)
- [Protocol Select specification](https://github.com/libp2p/specs/pull/349)

### 🛣️ Peer Routing Records
Expand Down