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.

Sign up for GitHub

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

Jump to bottom

feat(connection-limit): allow specific peers to bypass limit #5720

Merged
merged 21 commits into from
Feb 5, 2025
Merged

feat(connection-limit): allow specific peers to bypass limit #5720

merged 21 commits into from
Feb 5, 2025

Conversation

drHuangMHT
Copy link
Contributor

@drHuangMHT drHuangMHT commented Dec 6, 2024 •
edited
Loading

Description

Add bypass_peer_id on connection_limit::Behaviour to allow peers to bypass limit.
May close #5605

Notes & open questions

This implememtation does not distingush between local addresses and remote addresses, will that be a problem?

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

@drHuangMHT drHuangMHT changed the title feat(connection-limit): set bypass rules for connection by PeerId or Multiaddr feat(connection-limit): set bypass rules for connections Dec 6, 2024
@drHuangMHT
Copy link
Contributor Author

I also found that you can get a mutable reference to the ConnectionLimits at runtime but since all fields are private and all methods require ownership, you need to do clone and replace to actually modifiy it. Is that intentional?

@drHuangMHT drHuangMHT marked this pull request as draft December 6, 2024 08:06
elenaf9
elenaf9 reviewed Dec 6, 2024
View reviewed changes
Copy link
Contributor

@elenaf9 elenaf9 left a comment

Choose a reason for hiding this comment

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

I think adding bypass rules for a PeerId makes sense. I am not sure about having them for a MultiAddr as well.
When would one know the address of a trusted peer, but not it's PeerId?

@drHuangMHT
Copy link
Contributor Author

I think adding bypass rules for a PeerId makes sense. I am not sure about having them for a MultiAddr as well. When would one know the address of a trusted peer, but not it's PeerId?

I don't know, but trusting an address also kind of makes sense? Though this behaviour is not primarily used for managing trusts between peers.
Also this is brought up by the issue itself, @dariusc93 what do you think?

@drHuangMHT
Copy link
Contributor Author

I think adding bypass rules for a PeerId makes sense. I am not sure about having them for a MultiAddr as well. When would one know the address of a trusted peer, but not it's PeerId?

Also you can use the rule to allow a range of peers from an address, for example behind a load balancer and such, or a domain(I guess it only works for dialing). Allowing a range of addresses will grant even greater flexibility but it will be a bit difficult to implement.
We can also allow all connections from specific listeners.

elenaf9
elenaf9 reviewed Jan 4, 2025
View reviewed changes
Copy link
Contributor

@elenaf9 elenaf9 left a comment

Choose a reason for hiding this comment

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

We can also allow all connections from specific listeners.

Not sure I understand what you mean. Won't using the listeners PeerId do exactly that?

I still have a slight preference to only allow bypassing of connection limits based on PeerIds. In allow-block-list we also only operated on PeerIds and not on multiaddresses.
But I don't feel strongly about it, so if from a user perspective it's useful and needed I am okay with also bypassing based on addresses.

misc/connection-limits/src/lib.rs Outdated Show resolved Hide resolved
misc/connection-limits/src/lib.rs Outdated Show resolved Hide resolved
@dariusc93
Copy link
Member

Sorry for the late response. Looking at the comments and review, I think what we can do for now is exclude the address portion of the code and allow it based on PeerId alone and have a later discussion on if we should allow Multiaddr to be used as well. My train of thought in my issue #5605 was to not only allow PeerId but also specific Multiaddr (i.e if the local node wish to only allow connections from a specific relay, to allow connections from a specific address from the peer for content discovery, etc), but as i think about it more, I can imagine it getting more complex down the road. I could be wrong though on that and I may be overthinking that use-case, but in all I am not against just sticking with PeerId in this PR for now. Thoughts?

CC @drHuangMHT @elenaf9

@drHuangMHT drHuangMHT requested a review from elenaf9 January 23, 2025 12:43
dariusc93
dariusc93 reviewed Jan 31, 2025
View reviewed changes
Copy link
Member

@dariusc93 dariusc93 left a comment

Choose a reason for hiding this comment

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

Left a couple of comments. Can we also add a test for this feature?

misc/connection-limits/CHANGELOG.md Show resolved Hide resolved
misc/connection-limits/src/lib.rs Outdated Show resolved Hide resolved
elenaf9
elenaf9 approved these changes Feb 1, 2025
View reviewed changes
Copy link
Contributor

@elenaf9 elenaf9 left a comment

Choose a reason for hiding this comment

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

Thank you for the follow-ups @drHuangMHT! LGTM.

dariusc93
dariusc93 reviewed Feb 1, 2025
View reviewed changes
Copy link
Member

@dariusc93 dariusc93 left a comment

Choose a reason for hiding this comment

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

LGTM. Can you update the versions in both Cargo.toml (crate and workpace)? :)

@drHuangMHT
Copy link
Contributor Author

LGTM. Can you update the versions in both Cargo.toml (crate and workpace)? :)

Tests and version bump on the way.

jxs
jxs approved these changes Feb 3, 2025
View reviewed changes
Copy link
Member

@jxs jxs left a comment •
edited
Loading

Choose a reason for hiding this comment

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

LGTM! Thanks for working this out DrHuangMHT! ❤️
I'll let you address Darius's suggestions before merging it

@drHuangMHT drHuangMHT changed the title feat(connection-limit): set bypass rules for connections feat(connection-limit): allow specific peers to bypass limit Feb 5, 2025
@drHuangMHT drHuangMHT marked this pull request as ready for review February 5, 2025 02:43
@elenaf9 elenaf9 added the send-it label Feb 5, 2025
@mergify mergify bot merged commit 9db2ea0 into libp2p:master Feb 5, 2025
71 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dknopik dknopik dknopik left review comments

@elenaf9 elenaf9 elenaf9 approved these changes

@jxs jxs jxs approved these changes

@dariusc93 dariusc93 dariusc93 approved these changes

Assignees
No one assigned
Labels
send-it
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

connection-limits: whitelist PeerId or Multiaddr to bypass checks.
5 participants
@drHuangMHT @dariusc93 @jxs @elenaf9 @dknopik