search

ethersphere / swarm

Swarm: Censorship resistant storage and communication infrastructure for a truly sovereign digital society
https://swarm.ethereum.org/
GNU Lesser General Public License v3.0
489 stars 112 forks source link

build tool to generate swarm connectivity without relying on kademlia suggestpeer #1324

Open nonsense opened 5 years ago

nonsense commented 5 years ago

At the moment Swarm discovery is handled with the Kademlia.SuggestPeer functionality.

Given the amount of bugs we've had with depth and Kademlia and the problems with maxpeers limits and discovery, I think it will be beneficial to have a tool that builds the connectivity of our clusters and then validates they are actually correct, without relying on discovery and SuggestPeer.

Basically the tool should make it possible to:

  1. extract existing topology of a network, including all connections between peers below and above the depth
  2. apply an existing topology to a deployment on kubernetes, and also disabling the SuggestPeer and Discovery functionalities.
  3. periodically validate that 2 is performed correctly and that the deployment has the topology we expect (basically catching problems we might have with peers being dropped, etc.)

If we build such a tool, we would essentially split the problem of syncing and retrieval away from the topology of a network, having high degree of confidence that the network is connected as we expect it to be.

zelig commented 5 years ago

AFAIU this is what a snapshot and the p2p/simulations remote adapter is meant for.

  1. https://github.com/ethersphere/go-ethereum/issues/991

  2. https://github.com/ethersphere/go-ethereum/issues/1135

nonsense commented 5 years ago

@zelig even if is was currently possible (which it is not) to apply the snapshots of the p2p/simulations package to an environment on Kubernetes, we would still need a way to disable the hive discovery through the SuggestPeer functionality. You might start with one snapshot, but then discovery would kick in and modify the Kademlia table on a given node. So we should add functionality that disables that and relies only on the connectivity specified in the snapshot.

Additionally the p2p/simulations package starts nodes differently compared to a swarm binary, which is yet another abstraction that can introduce issues - I'd like a way to start a specific snapshot which is as close to a real Swarm environment as possible, and the p2p/simulations package is a bit too far away from that right now.

zelig commented 5 years ago

hive params Discovery is set to false with simulations and that disables suggestpeer et co to kick in. the hive does not interfere with snapshots. remote adapter should also disable swarm discovery on nodes.

remote adapter would start nodes by running the binary on a pod so in this case it would not be different

nonsense commented 5 years ago

@zelig based on current version on master the Discovery flag has no effect on SuggestPeer - check the Hive.connect method.

The remote adapter current is compiling a test binary, which has a completely different setup code, compared to a regular Swarm node. I'd rather we test Swarm from the perspective of real users as a first use-case, and only after add more complicated scenarios.

nonsense commented 5 years ago

@zelig can you please not micro-manage this issue - we have no working functionality to do what is described in the issue description.

Someone from the team should pick it up, and just solve it to 100%, while reviewing the current state of the codebase. If they have questions on how to do that, we can address them when they arise.

It seems to me that you are suggesting that this is not a real issue and that this is an already solved problem - with snapshots, remote adapters, discovery flags and what not - which is really not the case.