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

Finding Circuit Relay V2 servers #2545

Open
achingbrain opened this issue May 14, 2024 · 1 comment · May be fixed by #2563
Open

Finding Circuit Relay V2 servers #2545

achingbrain opened this issue May 14, 2024 · 1 comment · May be fixed by #2563
Assignees
Labels
effort/days Estimated to take multiple days, but less than a week exp/expert Having worked on the specific codebase is important kind/enhancement A net-new feature or improvement to an existing feature

Comments

@achingbrain
Copy link
Member

The existing approach is for Circuit Relay v2 servers to publish provider records for a pre-determined CID, then would-be relay clients look up providers of this CID. As the query travels through several nodes one of them may be a relay so will respond as a provider, otherwise the original provider records will be found which will return nodes functioning as relay servers.

This has some downsides:

  1. Only js-libp2p nodes do this.
    This was unilaterally implemented by js-libp2p four(ish) years ago and no other implementations followed suit, so there are a limited number of nodes publishing these records
  2. Large routing tables limit it's effectiveness
    As routing tables grow, the number of hops needed to locate the closest peers to the KAD-ID of the CID decreases so you are less likely to discover intermediate nodes as relays
  3. 20 nodes get overloaded
    As every js-libp2p node is publishing provider records for the same CID, the same 20 nodes should (in theory) be hosting all provider records for every js-libp2p node on the network. This is not scalable and is open to abuse.

Instead we will perform a random walk of the content routing and dial encountered peers. After identify has run we will discover relays in a more scalable way, at the cost of opening more connections.

This will work for node without much issue though browsers may need some further tweaking as they are sometimes limited in the number of connections they can open e.g. https://issues.chromium.org/issues/40069954

@achingbrain achingbrain added the need/triage Needs initial labeling and prioritization label May 14, 2024
@achingbrain achingbrain self-assigned this May 14, 2024
@achingbrain achingbrain added kind/enhancement A net-new feature or improvement to an existing feature exp/expert Having worked on the specific codebase is important effort/days Estimated to take multiple days, but less than a week and removed need/triage Needs initial labeling and prioritization labels May 14, 2024
@dhuseby
Copy link
Contributor

dhuseby commented May 21, 2024

Created awesome browser extension to debug this...

@achingbrain achingbrain linked a pull request May 28, 2024 that will close this issue
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/days Estimated to take multiple days, but less than a week exp/expert Having worked on the specific codebase is important kind/enhancement A net-new feature or improvement to an existing feature
Projects
Status: 🏃‍♀️In Progress
Development

Successfully merging a pull request may close this issue.

2 participants