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.

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

refactor(iroh-net): call-me-maybe improvements (no more tasks for queue, better logic on recv) #1752

Merged
merged 5 commits into from
Oct 29, 2023

Conversation

Frando
Copy link
Member

@Frando Frando commented Oct 27, 2023

Description

Removes the task spawning for queued call-me-maybes. Instead just keep them in a hashmap. This is possible now because sending call-me-maybes is sync anyway. We will lose them if the derp channel is full, which might be a problem, but that is already a problem on main.

Additionally removes ActorMessage::ReStun and instead moves the EndpointUpdateState onto Inner. One less thing to go over the main channel - not needed, because the EndpointUpdateState already is a concurrent data structure (with a mutex added for the next_update).

Also improves (hopefully) the logic when receiving a call-me-maybe: It now clears the recent_pong for all addresses not included in the call-me-maybe, and clears the best_addr trust if not included in the call-me-maybe.

Notes & open questions

Change checklist

  • Self-review.
  • Documentation updates if relevant.
  • Tests if relevant.

@dignifiedquire dignifiedquire force-pushed the iroh-net-refactor-netcheck-fix branch from 7d5f987 to d8775ab Compare October 27, 2023 12:39
@Frando Frando force-pushed the iroh-net-refactor-netcheck-fix-cmm-queue branch from e3fdc48 to 70380c0 Compare October 27, 2023 15:32
@Frando Frando changed the base branch from iroh-net-refactor-netcheck-fix to main October 27, 2023 15:32
@Frando Frando changed the title refactor(iroh-net): no more task spawns for queued call-me-maybes refactor(iroh-net): call-me-maybe improvements (no more tasks for queue, better logic on recv) Oct 27, 2023
log_endpoint_change(&eps);
if let Some(ref cb) = self.inner.on_endpoints {
cb(&eps[..]);
}
for (public_key, region_id) in self.inner.pending_call_me_maybes.lock().drain() {
self.inner
.send_or_queue_call_me_maybe(region_id, public_key);
Copy link
Contributor

Choose a reason for hiding this comment

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

shouldn't this force sending instead of potentially requeuing? not sure in either direction

Copy link
Member Author

Choose a reason for hiding this comment

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

Yea it won't requeue because endpoints.set was just called which means endpoints.is_fresh will always be true.
We could add a separate send_call_me_maybe method for clarity though.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think that would be good, to make the intent clear (given the complexity of this code.. )

Copy link
Member Author

Choose a reason for hiding this comment

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

Changed it to separate functions.

Copy link
Contributor

@dignifiedquire dignifiedquire left a comment

Choose a reason for hiding this comment

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

looks good, one question

github-merge-queue bot pushed a commit that referenced this pull request Oct 27, 2023
## Description

In a longer debugging session with @dignifiedquire we found out that
`wait_idle` will *always* wait on a close timer for a few 100 ms before
actually completing. If application layer protocols always take care of
finishing their work (which we do) this is not needed at all. Also the
magicsock will very likely stay around long enough to still send out the
close frame.

This together with #1752 brings the runtime of the `derp_connect_loop`
test down from 15s to 4s on my machine! First round is 2-3s (due to bugs
in netcheck making it too slow likely) and subsequent round are all
>500ms!

## Notes & open questions

<!-- Any notes, remarks or open questions you have to make about the PR.
-->

## Change checklist

- [ ] Self-review.
- [ ] Documentation updates if relevant.
- [ ] Tests if relevant.
@Frando Frando force-pushed the iroh-net-refactor-netcheck-fix-cmm-queue branch from 70380c0 to a337405 Compare October 28, 2023 14:47
@Frando Frando added this pull request to the merge queue Oct 29, 2023
Merged via the queue into main with commit 376748c Oct 29, 2023
@dignifiedquire dignifiedquire deleted the iroh-net-refactor-netcheck-fix-cmm-queue branch October 29, 2023 20:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

2 participants