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

Brainstorm and refactor the discovery process and address book #2746

Open
tomaka opened this issue Sep 14, 2022 · 0 comments
Open

Brainstorm and refactor the discovery process and address book #2746

tomaka opened this issue Sep 14, 2022 · 0 comments

Comments

@tomaka
Copy link
Contributor

tomaka commented Sep 14, 2022

There exists multiple systems that are spread between the network services and the network/service:

  • "Out slots" are assigned by the network services following the suggestions of the network/service.
  • Kbuckets, used to determine which PeerIds to hold (prevents memory explosion) and answer Kademlia requests.
  • For each peer, a list of addresses and whether we are connecting or connected to it.
  • A ban system in network services, where we prevent connections to the same peer for 20 seconds after a disconnect.

This is in general overly complicated and hard to prove correct.
Additionally, the network services don't have enough control over this process.

The whole thing should be clarified and simplified in the code.

mergify bot added a commit that referenced this issue Nov 23, 2022
Close #1531
cc #2746

This PR renames `is_unreachable` to `is_bad_address`.
It is generally not possible to know whether an address is definitely
unreachable or not. The only situation where we can affirm that an
address is definitely unreachable is if our implementation doesn't
support a certain protocol that it uses.

This matches what the browser node already does anyway.

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
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