Skip to content

Conversation

@ramfox
Copy link
Member

@ramfox ramfox commented Nov 14, 2025

Description

Prune paths that are not actively being used, about to be dialed, or old.

Notes and Questions

The logic of gathering all of the relevant information is in the fn prune_ip_paths function, not in the self.prune_ip_paths method on EndpointActorState. Separating these out made it easier to test.

Used AI to help write tests & reduce allocations when working through the paths.

keep_path is where we can play around in the future with what exactly we want to keep, based on the PathState, if we want to get more strict or particular as we learn more.

Right now we:

  • keep paths that are open
  • keep paths that are waiting to be opened
  • keep paths that have not ever been pinged
  • have at least one source that was given to us less that 2 mins ago

This means:

  • we only prune paths if they are inactive, have previously been pinged (so we attempted to hole punch them) and have not been given to us or connected in over 2 mins

Also, we only do prune this if there are more that 20 inactive paths open.

I've added prune_ip_paths anytime we insert a path to the EndpointActorState::paths. However, there are two places I did not add this check, that maybe I should. But my brain is a bit fuzzy right now, so I will do another review about where these checks should go.

That being said, I think this is ready for initial review, at least.

@n0bot n0bot bot added this to iroh Nov 14, 2025
@github-project-automation github-project-automation bot moved this to 🏗 In progress in iroh Nov 14, 2025
@matheus23 matheus23 changed the base branch from main to feat-multipath November 17, 2025 08:17
@github-actions
Copy link

github-actions bot commented Nov 17, 2025

Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/3666/docs/iroh/

Last updated: 2025-11-20T17:10:25Z

@ramfox ramfox changed the title wip feat: prune old, inactive paths feat: prune old, inactive paths Nov 17, 2025
@ramfox ramfox requested a review from flub November 17, 2025 19:04
@ramfox ramfox self-assigned this Nov 17, 2025
@ramfox ramfox added this to the v0.96 milestone Nov 17, 2025
@ramfox ramfox marked this pull request as ready for review November 17, 2025 19:09
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Err.. I think this file should be removed probably. I think it's from a stray merge, right?

Comment on lines 432 to 436
self.paths
.insert(path_remote, Source::Connection { _0: Private });
self.select_path();
// TODO(ramfox): do we need to prune paths here?
self.prune_ip_paths();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes!
I think every time we call paths.insert we should also call self.prune_ip_paths(). Because the number of paths might get increased above the high watermark due to the insert.


trace!("ping received, triggering holepunching");
self.trigger_holepunching().await;
// TODO(ramfox): potentially prune addrs here?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think we should do so here, since we have paths.inserted above.

self.paths.disco_ping_sent(addr.clone(), msg.tx_id);
self.send_disco_message(addr, disco::Message::Ping(msg))
.await;
// TODO(ramfox): potentially prune addrs here?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I don't think so. We only need to prevent the paths from becoming excessively populated. We can prevent that by checking each time we paths.insert.

Comment on lines +163 to +165
if self.paths.len() < MAX_INACTIVE_IP_ADDRESSES {
return;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've already done this check in RemoteStateActor::prune_ip_paths.
I think I'd be in favor of removing this check and inlining the prune_ip_paths call below.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: 🏗 In progress

Development

Successfully merging this pull request may close these issues.

3 participants