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

use the expected_dk metric on each step of GET queries, not just storing nodes #39

Closed
Nuhvi opened this issue Nov 18, 2024 · 1 comment
Assignees

Comments

@Nuhvi
Copy link
Collaborator

Nuhvi commented Nov 18, 2024

Currently we only use the expected_dk metric after finishing the GET query to find out where to store data.

However there is a possibility that the first response to a GET query contain nodes that are all Sybil nodes and all closer to the target than any other nodes. Because the way the query works, we will only consult these Sybil nodes, and thus the responders ClosestNodes, will all be Sybil.

Usually nothing will be affected by this, since most of the time expected_dk is at the 20th node anyway.
But when the current dht size estimation is 0 because there are no previous queries, we might take too many nodes to query in parallel at once, that might cause too many packet to be dropped by our router. So we need to check #38

@Nuhvi Nuhvi self-assigned this Nov 18, 2024
@Nuhvi
Copy link
Collaborator Author

Nuhvi commented Nov 29, 2024

The only way this could happen is if your routing table is poisoned ... maybe we can make some checks for keeping buckets diverse ID and IPs wise ... but not in the query.

@Nuhvi Nuhvi closed this as completed Nov 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant