swarm: enable p2p/discovery and disable dynamic dialling #19189
Merged
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.
This PR is re-enabling p2p discovery, but disabling the dynamic dialling functionality - the reason why we didn't want to have the p2p discovery in the first place.
The reason for this is - the
hive
protocol and theKademlia
table implementation on Swarm side does not update the underlay addresses of peers. More specificallyKademlia.Register
does not update the underlay addresses ever, butKademlia.On
andKademlia.Off
do. This means that sometimes we are left with outdated destinations for nodes in our state store.The
p2p
package handles that with:Namely, if
dialling
fails, it tries toresolve
an up-to-date destination for the node - something that is only done whendiscovery
is enabled.Bottom line:
hive
protocol relies heavily on the discovery functionality in thep2p
package, so for now it is not wise to disable discovery onp2p
.Addresses: ethersphere/swarm#1268
I also considered solving this directly on Swarm side, but the
hive
protocol implementation is not straight-forward and it is not clear how to determine what an up-to-date / accurate node destination is. What happens is that when a new node starts up and loads an out-dated node destination, it might receive ahive
message with a different destination for a given node, and it can't determine which one is correct, without trying them both. We don't have functionality to do that, and implementing this seems like a major change in thehive
protocol.