Repository navigation
Simplify ConnectionHandler trait by removing as many associated types as possible #2863
Description
Simplify the ConnectionHandler interface. This is one of the first interfaces users get in touch with when the implement their own protocols. Making it as simple as possible without removing functionality should be the goal. All but {To,From}Behaviour should be removed and we should directly hand the negotiated stream to the ConnectionHandler without any form of "upgrade".
### Sub-epics
- [ ] https://github.com/libp2p/rust-libp2p/issues/4306
- [ ] https://github.com/libp2p/rust-libp2p/issues/3268
- [ ] https://github.com/libp2p/rust-libp2p/discussions/4585
- [ ] https://github.com/libp2p/rust-libp2p/issues/3591
### Use `ReadyUpgrade` everywhere
- [ ] https://github.com/libp2p/rust-libp2p/issues/4075
- [ ] https://github.com/libp2p/rust-libp2p/pull/4563
- [ ] https://github.com/libp2p/rust-libp2p/pull/3914
- [ ] https://github.com/libp2p/rust-libp2p/issues/4649
- [ ] refactor(dcutr): use `ReadyUpgrade` for `{In,Out}boundUpgrade`
- [ ] refactor(gossipsub): use `ReadyUpgrade` for `{In,Out}boundUpgrade`
### Migration plan
- [ ] https://github.com/libp2p/rust-libp2p/issues/4307
- [ ] https://github.com/libp2p/rust-libp2p/issues/4521
- [ ] https://github.com/libp2p/rust-libp2p/issues/4697
- [ ] https://github.com/libp2p/rust-libp2p/issues/4790
Reacted by João Marcos
Activity
thomaseizinger commentedon Sep 2, 2022
thomaseizinger commentedon Sep 2, 2022
thomaseizinger commentedon Sep 2, 2022
mxinden commentedon Sep 6, 2022
mxinden commentedon Sep 12, 2022
thomaseizinger commentedon Oct 19, 2022
mxinden commentedon Oct 21, 2022
thomaseizinger commentedon Dec 19, 2022
thomaseizinger commentedon Jan 10, 2023
thomaseizinger commentedon Jan 11, 2023
mxinden commentedon Jan 18, 2023
[-]swarm/handler: Decouple `ConnectionHandler` from `{In,Out}boundUpgrade`[/-][+]Decouple `ConnectionHandler` from `{In,Out}boundUpgrade`[/+][-]Decouple `ConnectionHandler` from `{In,Out}boundUpgrade`[/-][+]Simplify `ConnectionHandler` trait by removing as many associated types as possible[/+]refactor(identify): use `ReadyUpgrade` for `{In,Out}boundUpgrade`
refactor(request-response): don't use upgrade infrastructure
refactor(request-response): don't use upgrade infrastructure
RGBCube commentedon Oct 18, 2025
A question I have is would it be possible to remove
polland add an async fn that gets run until completion? Traits have async fn support without boxing now, and I don't think libp2p needs the handlers to be dyn-safe. Would remove a lot of allocations (that are very hard to avoid without janky nightly features) and make code much cleaner too. This would need a new major version.dariusc93 commentedon Oct 18, 2025
an async desugar to
impl Futureand await is no different than polling in place so it would probably be better to leave things as is. There are some aspects of the codebase that uses async-trait that could use RIIT instead (ie request-response) but other parts may still need to be boxed.thomaseizinger commentedon Oct 19, 2025
The main and still unsolved issue of
async fnare mutable borrows. You can only construct a singleasync fnthat borrows something mutably. That makes concurrency pretty difficult.Using something like
FuturesUnorderedor the utilities fromfutures-boundedetc makes it pretty ergonomic and still allows for good (and controlled!) concurrency.refactor(identify): use `ReadyUpgrade` for `{In,Out}boundUpgrade`
refactor(request-response): don't use upgrade infrastructure