Repository: https://github.com/bittorrent/scout

The Kademlia/Bittorrent DHT protocol still requires an initial node to bootstrap access the DHT. In Bittorrent, a set of known-good nodes is encoded into the .torrent file (or clients can use previously-discovered nodes they might happen to know about, or router.bittorrent.com as a last-resort fallback).

How does Scout bootstrap?

Scout uses BitTorrent Inc's bootstrap servers at router.bittorrent.com and router.utorrent.com.

In other words, nothing different than what we have now.

Oh, I wonder if this means that Bittorrent Inc's own clients (e.g. uTorrent) are helping maintaining the DHT store by default now.

uTorrent has implemented BEP44 (storing data in the DHT) for years, as has libtorrent. Those two clients combined make up a large majority of the bittorrent DHT so BEP44 support is quite reliable now.

Thanks!

At least according to Wikipedia references, BitTorrent Inc's own client had mainline DHT support since version 4.2 (~2005). uTorrent seems to have added support for mainline DHT some time before the acquisition as well. There's a good torrentfreak post from the 10 year anniversary that covers the history pretty well: https://torrentfreak.com/bittorrents-dht-turns-10-years-old-...

I'm guessing that your "by default now" may actually be in regards to BitComet and the v0.60 client that upset some folk?

Besides the BEP44 implementation magila mentioned, BitTorrent Inc. also assists with the DHT by operating a public bootstrap server at router.[bittorrent|utorrent].com, and provides the source too: https://github.com/bittorrent/bootstrap-dht

What is the key difference between "central servers" and "bootstrap servers"?

I mean DHT is "decntralized" once the client has a copy, but initially a client has to get a copy of it from somehwere.

And unless every client gets the DHT from a different source, the system seems "centralized" in that sense.

Clients are allowed to store nodes received by the bootstrap servers and use them again at next startup, so the centralization is only on first run of the app.

You could include a snapshot of the DHT on compile time.

Yes, by "the DHT store" I meant BEP44's new (2014) emergent database on top of the DHT; not the DHT itself.

Thanks for the answer.

IPFS should be looking at this. They had a number of NAT traversal issues this might help with.

IPFS dev here -- judging from a quick look, Scout uses NAT-PMP and UPnP for NAT traversal, so it basically has the same occasional NAT issues as everybody else in the P2P space. By the way, sometimes NAT issues are the fault of routers handed out by ISPs. The quality of these is often less than ideal.

(A pretty cool approach to circumventing NAT issues is a proper routed overlay network, which we plan to implement in libp2p soon: https://github.com/ipfs/notes/issues/143)

I should probably also mention that even if you implement the existing NAT traversal protocols correctly, these aren't satisfying solutions. We really need that damn time machine already, the End-to-End Principle should have been an End-to-End Law.

I'd love to see more effort to encourage laypeople to use and ask for IPv6. Imagine if instead of Microsoft and Sony inventing terms like "strict NAT" vs "open NAT" for how their gaming consoles describe network issues, they had those consoles inform their users that they can't host a game because their ISP doesn't provide IPv6 connectivity.

Considered using pwnat?

http://samy.pl/pwnat/

Can this be used to build a peer to peer VPN with no static IPs?