search

jackpal / Taipei-Torrent

A(nother) Bittorrent client written in the go programming language
BSD 3-Clause "New" or "Revised" License
842 stars 123 forks source link

IPv6 DHT issues. #78

Open spikebike opened 9 years ago

spikebike commented 9 years ago

Greetings,

I added IPv6 to Nictuku's DHT implementation. It's a reasonable implementation, worked well in my testing, and involved minimal lines of code because Go hides most of the IPv4/IPV6 differences.

Because of BEP 32's recommendation, I kept the IPv4 and IPv6 routing tables completely seperate. This was most easily done by just adding v4/v6 flag to the config and generating a DHT for each. As a result you won't get IPv4 and IPv6 peers without some changes to clients using Nictuku's DHT.

There's various ways to fix this: 1) tweak Taipei-Torrent to launch two go threads one for IPv6 one for IPv4, just like dht/example/main6.go 2) rework DHT to maintain 2 internal routing tables and add logic for tracking which message updates which DHT 3) ignore the BEP and have one routing table for all peers (v4 and v6). I can't think of any downside. Seems like contacting the N nearest peers to your target is best, regardless of which are IPv4 and which are IPv6. After all if a size X routing table is optimal for Y peers why care about the mix of IPv4 vs IPv6 over time?

I'm willing to help, figured as a user of the DHT you might have an opinion on the above.

nictuku commented 9 years ago

I like option 1. The cost of those two goroutines is negligible. Also when would it make sense to return v6 addresses to a v4 remote peer or vice versa?

I do think it's nice to keep a separate table for v6 because otherwise the sheer number of v4s will push away the v6 nodes from the table. So even if we had a single node, it would make sense for v4/v6 addresses to be kept in independent spaces.