libp2p / libp2p/rust-libp2p

swarm: optimize compute of locally supported protocols

Open
#4,284 9 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

decision-pending difficulty:moderate help wanted
Dominant language
Rust
Stars
5.6k
Forks
1.3k
Avg merge
8h 47m
Merged PRs (30d)
19

Description

For context, see this discussion: https://github.com/libp2p/rust-libp2p/discussions/3840.

This issue captures the idea mentioned in https://github.com/libp2p/rust-libp2p/discussions/3840#discussioncomment-6605941 as a concrete task to work on.

What we want to achieve is a consistent view of our locally supported protocols by the ConnectionHandler. Every state change in the ConnectionHandler may change the supported protocols (i.e. what is returned from listen_protocol).

As the linked discussion shows, computing this on every poll iteration is quite expensive. Skipping the computation on some iterations may risk that the view is outdated. The key requirement for the optimization is thus that we must ensure that if we return Poll::Pending from the task AND our view is potentially stale to eventually recompute it.

The concrete suggestion in the linked issue is:

  • Introduce a flag that tracks whether our view of the supported protocols is potentially outdated: maybe_outdated.
    • This flag must flip to false every time we update the supported protocols.
    • It must flip to true on every iteration where we decide to skip the computation.
  • Introduce a timestamp that tracks, when we last updated our view of the supported protocols.
  • If we updated it within the last 5 seconds, don't update it again.
  • If the end up returning Poll::Pending and maybe_outdated is set to true, register a timer to wake us up in 5 seconds.

In addition, I'd suggest that we also compute the difference to our supported protocols upon every inbound stream. We need to collect all protocols anyway at this point so we might as well use that data efficiently!

I believe that this algorithm has the following properties:

  • Short, consecutive wake-ups of the Connection don't end up re-computing the supported protocols.
  • The state is eventually consistent by ensuring a wake-up and recomputation in case we suspend the connection with a potentially stale view.
  • The connection stays suspended and does not wake up unnecessarily in case we have an up-to-date view of the supported protocols.

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 with the ConnectionHandler implementation, especially the listen_protocol computation, poll path, and inbound-stream handling. Trace how supported protocols are collected and how Poll::Pending is returned. Done means avoiding unnecessary recomputation while ensuring a potentially stale view causes a wake-up and eventual recomputation.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
networking
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.