[switch] Have dial backoffs be multiaddr specific instead of peer specific #426
Comments
|
Seeing the PR for clearing a blacklist when a connection is established made me wonder if we should also do blacklist removal by multiaddr? |
|
If we observe a connection on that multiaddr then yes we should remove it from the blacklist. |
|
We also had an issue with IPFS interop trying to dial a peer several times ipfs/interop#77. |
jacobheun
changed the title
daviddias
changed the title
maschad
pushed a commit
to maschad/js-libp2p
that referenced
this issue
Jun 21, 2023
As the `k-bucket` documentation [here](https://github.com/tristanls/k-bucket/blob/master/README.md#kbuckettoiterable) indicates, `toIterable` yields contact objects, **not** `KBucket` objects. Here, the contact objects are `KBucketPeer` objects. You can check this in the code [here](https://github.com/tristanls/k-bucket/blob/3aa5b4f1dacb835752995a25409ab319d2070b9e/index.js#L413) - the delegated yield `yield * node.contacts` will yield each of the elements of the `node.contacts` array in order. Co-authored-by: Alex Potsides <alex@achingbrain.net>
maschad
pushed a commit
to maschad/js-libp2p
that referenced
this issue
Jun 21, 2023
## [7.0.1](libp2p/js-libp2p-kad-dht@v7.0.0...v7.0.1) (2023-03-10) ### Bug Fixes * correct `KBucketTree` types ([libp2p#426](libp2p/js-libp2p-kad-dht#426)) ([ea8e6d0](libp2p/js-libp2p-kad-dht@ea8e6d0)), closes [/github.com/tristanls/k-bucket/blob/3aa5b4f1dacb835752995a25409ab319d2070b9e/index.js#L413](https://github.com/libp2p//github.com/tristanls/k-bucket/blob/3aa5b4f1dacb835752995a25409ab319d2070b9e/index.js/issues/L413) * update p-queue types ([libp2p#428](libp2p/js-libp2p-kad-dht#428)) ([f5b85fc](libp2p/js-libp2p-kad-dht@f5b85fc)) ### Trivial Changes * replace err-code with CodeError ([libp2p#413](libp2p/js-libp2p-kad-dht#413)) ([e05d2a0](libp2p/js-libp2p-kad-dht@e05d2a0)), closes [js-libp2p#1269](libp2p#1269) * Update .github/workflows/semantic-pull-request.yml [skip ci] ([a70ab3f](libp2p/js-libp2p-kad-dht@a70ab3f)) * Update .github/workflows/semantic-pull-request.yml [skip ci] ([1652c6c](libp2p/js-libp2p-kad-dht@1652c6c)) * Update .github/workflows/semantic-pull-request.yml [skip ci] ([ea13c2a](libp2p/js-libp2p-kad-dht@ea13c2a))
|
Closing due to staleness |
github-project-automation
bot
moved this from 🥞Weekly Candidates/Discuss🎙
to 🎉Done
in js-libp2p
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently when we are not able to dial a peer we blacklist the peer with an exponential backoff. Really we should be backing off on multiaddrs. It's very possible that we can learn new, dialable multiaddrs for a peer after they've been blacklisted and we should be able to immediately attempt those dials.
Context: ipfs/interop#70 (comment)
The text was updated successfully, but these errors were encountered: