-
Notifications
You must be signed in to change notification settings - Fork 213
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
Conversation
7d5f987
to
d8775ab
Compare
e3fdc48
to
70380c0
Compare
iroh-net/src/magicsock.rs
Outdated
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); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.. )
There was a problem hiding this comment.
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.
There was a problem hiding this 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
## 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.
70380c0
to
a337405
Compare
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 theEndpointUpdateState
ontoInner
. One less thing to go over the main channel - not needed, because theEndpointUpdateState
already is a concurrent data structure (with a mutex added for thenext_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 thebest_addr
trust if not included in the call-me-maybe.Notes & open questions
Change checklist