-
Notifications
You must be signed in to change notification settings - Fork 919
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
feat(share/discovery): Discard method #2207
Conversation
It seems like with current solution peer could be rediscovered right away. Could we move discarded peer to some set that will prevent it from be in discovery set? |
Nvm, answer was in description. I'm a bit sleepy and skipped reading it |
...
|
For the integration it may be easier if the Discard API returns a boolean, if it was in discovery or not. This is because: For removing a peer from the pool, we rely on discovery to call our callback, which calls pool.remove Not ideal but its a solution |
Fixes celestiaorg#2204 Regarding the case where we exhausted all the peers on the network and backed them all off. It can happen on the smaller network, and in the worst case, the node will wait 10 minutes(the default backoff time), which is acceptable considering peers from shrexsub celestiaorg#2105
Fixes #2204
Regarding the case where we exhausted all the peers on the network and backed them all off. It can happen on the smaller network, and in the worst case, the node will wait 10 minutes(the default backoff time), which is acceptable considering peers from shrexsub #2105