Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Persisting/seeding a routing table #383
Persisting/seeding a routing table #383
Changes from 14 commits
1c23cfc
5ea52c0
97e5070
fa64c22
1e0db1e
348aa88
f7cfb4f
978f077
a8a1cf9
1f09fcb
62b33eb
9965eba
bdeb350
a6cf077
dfa73aa
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd really love to store the routing table before we shut down. However, because we don't control the order in which libp2p components shut down, we might end up storing the routing table after other components that are also running their shutdown logic have disconnected peers. As a result, we'd end up storing a crippled routing table.
On the other hand, I guess a degree of randomness here is good. Otherwise, if an attacker found a way to both poison the table and force a shutdown, they could permanently bork the routing table if the peer saved the poisoned one every time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what you mean. So, in it's current form, this code could persist an empty RT if the snapshotting go-routine fires after all peers have been dropped from the RT, but Dht hasn't been closed yet.
However, this can also prove to be a blessing in disguise because storing an empty RT & then seeding with bootstrap peers after we restart could save us from ALWAYS storing a poisoned RT if an attacker messed up our RT and found a way to immediately shut us down.
So, let's see how the current implementation works in practise & fix it if required ?