-
Notifications
You must be signed in to change notification settings - Fork 225
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make "auto" mode more forgiving #564
Comments
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:
Hiding complexity (creating two DHTs etc) this way is user friendly, and you can choose a default behavior in a more explicit fashion. |
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)? |
Interesting! Routing-helpers opens many universes of possibitilies. I would:
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? |
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 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.
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. |
We've added a new "dual" package with an easy-to-use constructor for the dual DHT. Closing in favor of #597. |
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:
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?
The text was updated successfully, but these errors were encountered: