Make "auto" mode more forgiving

[Stebalien]

Proposal: Switch into server mode after some small timeout if we still have an "unknown" reachability status. Then, switch back to client mode if we're told that we are, in fact, undailable.

Currently, the "Auto" DHT mode is very strict. Nodes refuse to join the network until they learn that they're dialable. Unfortunately, this means that homogeneous nodes either (a) not running AutoNAT servers or (b) all running on the same unroutable (private) network, will never form a DHT.

We planned on fixing this in go-ipfs by running two DHTs: one private and one public. However:

1. All libp2p users would have to do this manually and that's not very user friendly.
2. We've always been a bit concerned that these private DHTs might cause performance issues as nodes will likely end up putting provider records to every other node on the same private network.
3. This only covers the second case, not the first where nobody is running an AutoNAT server.

Thinking through this, I realized that an alternative is just switch to becoming a server if nobody is telling us we're undailable. That will fix the offline and/or local network use-case and we'll switch back into client mode the second we dial the public network.

Thoughts?

[hsanjuan]

I would avoid as much second-guessing as possible and let the users tell you, via options, how they plan to use the DHT for:

dht.New(..., dht.WANMode(off/auto/server/client), dht.LANMode(off/auto/server/client)...)

Hiding complexity (creating two DHTs etc) this way is user friendly, and you can choose a default behavior in a more explicit fashion.

[Stebalien]

Note: the plan is to do this outside of go-libp2p-kad-dht using https://github.com/libp2p/go-libp2p-routing-helpers. But doing it inside might simplify things (from a user's perspective)?

[hsanjuan]

Interesting! Routing-helpers opens many universes of possibitilies. I would:

• Take this chance to rename IpfsDHT to DHT or something else. It is not going to be anymore the IPFS DHT really. The behaviour changes are deep and may have unintended consequences. They make this a good moment to break and force users through the release notes to understand the real impact (and all the amazing features that can be now used).

• Create a new ipfs/go-ipfs-dht package to create a Routing object with optimal values for IPFS (validators, double-dht appoach, etc). This is used by go-ipfs and can be re-used by anyone wanting to join the global DHT (or a DHT that works for IPFS-y things, like ipns) and they get upgrades and ensured compatibility for free (unlike now, when we must follow the dht package and make sure we configure it correctly and stay in sync with how go-ipfs configures it).

• go-libp2p-kad-dht does not have to second guess users anymore and can just be straightforward in providing a single DHT thing.

• go-ipfs-dht optimizes for the IPFS usecase and serves as living example on how to use kad-dht, hiding the complexity for those that don't need to see it.

• Documentation links both packages, making sure users learn about go-ipfs-dht and go-libp2p-kad-dht and vice-versa.

• Bonus points are libp2p examples on how to do parallel DHTs manually for anyone with specific needs.

I think you could potentially get around this without impacting users much but we should just take the chance and make things explicit.

Does this make any sense?

[willscott]

The direction I've been imagining for how auto mode might work here is to have the connectivity detection code (go-libp2p-autonat) act in its service mode when in an unknown state.

In a lan / vpn context, that would mean that nodes that connect to each other would learn they are reachable by each-other, which should transition them into a network.Reachability of Reachable. At that point they will transition to DHT server mode.

In a public IPFS context, NAT'ed nodes will with very high probability learn that they are not connectable, because their initial connections will be to bootstrapping nodes that will fail to connect back to them. As such they'll go from unknown to unreachable, and will not advertise themselves as DHT servers, which seems desirable in that case.

[aarshkshah1992]

@willscott

In a public IPFS context, NAT'ed nodes will with very high probability learn that they are not connectable, because their initial connections will be to bootstrapping nodes that will fail to connect back to them. As such they'll go from unknown to unreachable, and will not advertise themselves as DHT servers, which seems desirable in that case.

Isn't this something we already do because bootstrapping nodes are already AutoNAT servers ? This should just work as is without any changes. I think @Stebalien 's point mostly concerns private networks or custom setups where no one is running AutoNAT server's OR the AutoNAT servers aren't helpful because everyone is on the same network.

The direction I've been imagining for how auto mode might work here is to have the connectivity detection code (go-libp2p-autonat) act in its service mode when in an unknown state.

You mean the Autnnat client act as an AutoNAT server ? That will muddle the code. Also, I am not sure this will work for private networks/LAN's because the AutoNat server does NOT dial back peers on the same network.

[Stebalien]

We've added a new "dual" package with an easy-to-use constructor for the dual DHT. Closing in favor of #597.