Explicitly set bootstrap/fallback nodes

[anacrolix]

Currently bootstrapping the routing table requires connecting to the bootstrap nodes manually. However if (when) the routing table later empties, this process of reconnecting to bootstrap nodes again must be done manually be the user, and isn't clear, or idiomatic for DHT operation. I propose instead to add a callback returning addresses to restart the DHT node when the routing table is empty. See #294 which is directly affected by this behaviour. See also #254 (comment) where this strategy is described. #254 and #283 reduce the impact of this missing feature, but aren't sufficient.

[anacrolix]

@jayarjo do you have some insight or concerns?

[jayarjo]

@anacrolix js version of libp2p-kad-dht mentions that it implements Peer Discovery and then it turned out that it's not. So I was following the thread of issues from there and on this one came to conclusion that the whole feature is not really functional at the moment. That's it.

Maybe you folks should remove Peer Discovery badge from js-libp2p-kad-dht readme for now.

[raulk]

@vasco-santos @jacobheun ^^ could you review @jayarjo's comment?

[jacobheun]

js version of libp2p-kad-dht mentions that it implements Peer Discovery and then it turned out that it's not.

There's some confusion here that I can hopefully clarify, and we can update libp2p/js-libp2p-kad-dht#44 to be more explicit. Random Walk in the DHT does work, and is quite effective at discovering peers. As far as the peer-discovery interface is concerned, random walk is implementing it. The problem (really just an annoyance, there's no runtime impact) is that Random Walk isn't added to js-libp2p's peer discovery services and instead exists and is managed solely by the DHT. Also, interface-peer-discovery actually needs tests https://github.com/libp2p/interface-peer-discovery/issues/6.

@jayarjo I'm not sure what concern you have with this particular issue. Is it the issue with reconnecting to the Bootstrap peers?

[anacrolix]

It's worth noting that (I think) random walk is used heavily in the Go DHT implementation because bootstrap traversals toward a node that actually exists reuses the code that finds addresses for a node, and terminates prematurely (for a bootstrap) upon finding it. Random walk is not standard behaviour for a DHT, afaik, but it has its uses.

[anacrolix]

I'm suggesting an option to the DHT:

SetFallbackNodes(func() []PeerInfo)

By default this would be a function returning the default bootstrap nodes in the appropriate form.