-
Notifications
You must be signed in to change notification settings - Fork 439
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
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
This was referenced May 14, 2024
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
Created awesome browser extension to debug this... |
3 tasks
achingbrain
added a commit
that referenced
this issue
Jun 6, 2024
Instead of publishing provider records for a pre-shared CID to find circuit relay servers, perform a random walk and attempt to make a reservation on any relay peers discovered. Fixes #2545
Merged
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
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:
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
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
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
The text was updated successfully, but these errors were encountered: