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

fix(mdns): Don't expire mDNS nodes on connection close #3367

Merged
merged 10 commits into from
Jan 27, 2023

Conversation

felinira
Copy link
Contributor

@felinira felinira commented Jan 23, 2023

Description

mDNS records should not be expiring when an unrelated connection timeout with said peer is reached.

Fixes #3309.

Links to any relevant issues

#3309

Change checklist

  • I have performed a self-review of my own code
  • I have made corresponding changes to the documentation
  • I have added tests that prove my fix is effective or that my feature works
  • A changelog entry has been made in the appropriate crates

@felinira felinira changed the title Don't expire mDNS nodes on connection close fix: Don't expire mDNS nodes on connection close Jan 23, 2023
@felinira felinira changed the title fix: Don't expire mDNS nodes on connection close fix(mdns): Don't expire mDNS nodes on connection close Jan 23, 2023
Copy link
Contributor

@thomaseizinger thomaseizinger left a comment

Choose a reason for hiding this comment

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

Thanks!

Can we add a test for this? It should be reasonably straight-forward to:

  1. Boot up two nodes listening on TCP
  2. Have them discover via mDNS
  3. Connect to them
  4. Disconnect them
  5. Assert that we can still connect to them by only specifying the PeerId, thus ensuring that the mDNS behaviour still uses the previously discovered record

protocols/mdns/CHANGELOG.md Outdated Show resolved Hide resolved
@felinira
Copy link
Contributor Author

I implemented the test only for the async-std backend. Should this be duplicated for tokio or possibly live somewhere else?

@thomaseizinger
Copy link
Contributor

I implemented the test only for the async-std backend. Should this be duplicated for tokio or possibly live somewhere else?

That is fine, thank you :)

Copy link
Contributor

@thomaseizinger thomaseizinger left a comment

Choose a reason for hiding this comment

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

There seems to be a typo in the test name, otherwise LGTM :)

@felinira
Copy link
Contributor Author

The typo helped me realize I somehow committed a working copy of the test instead of the final result. This one should work though.

Comment on lines 159 to 166
for (peer, addr) in peers {
if peer == *b.local_peer_id() && !dialed {
// Connect to all addresses of b to 'expire' all of them
a.dial(addr)?;
dialed = true;
}
}
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Would it be better to not iterate and just take the first one? Overriding the boolean state multiple times seems a bit odd.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The first one might not be b but someone else or even a. But you are right this was a bit convoluted.

protocols/mdns/tests/use-async-std.rs Outdated Show resolved Hide resolved
@felinira
Copy link
Contributor Author

Ah, now this doesn't work either because it passes the without the MR again.

@felinira
Copy link
Contributor Author

This works now. This test is a bit tricky because it might happen that the same peer is discovered multiple times and therefore it needs quite a bit of logic to determine the current state to make sure we are not introducing the address again at a later time.

Copy link
Contributor

@thomaseizinger thomaseizinger left a comment

Choose a reason for hiding this comment

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

One clippy failure, otherwise LGTM!

@thomaseizinger
Copy link
Contributor

@Mergifyio refresh

@mergify
Copy link
Contributor

mergify bot commented Jan 26, 2023

refresh

✅ Pull request refreshed

@thomaseizinger
Copy link
Contributor

@Mergifyio refresh

@mergify
Copy link
Contributor

mergify bot commented Jan 26, 2023

refresh

✅ Pull request refreshed

thomaseizinger
thomaseizinger previously approved these changes Jan 27, 2023
@mergify mergify bot dismissed thomaseizinger’s stale review January 27, 2023 01:14

Approvals have been dismissed because the PR was updated after the send-it label was applied.

@mergify mergify bot merged commit e2b3c11 into libp2p:master Jan 27, 2023
Copy link
Member

@mxinden mxinden left a comment

Choose a reason for hiding this comment

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

👍 thanks for the help here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

mDNS records expire when connection times out
3 participants