I2p support

[eyedeekay]

No description provided.

[xgfone]

You need to resolve the conflicts.

[eyedeekay]

Wait how did this show back up here? I moved my fork and severed the upstream relationship when you rejected the previous version, I was just going to continue my fork separately. Filing this PR was a mistake of some kind, probably made while I was setting up my fork.

However, if you've changed your mind about I2P support I'll resolve the conflicts and make it work with the new CompactResponse struct and resolve the conflicts.

[xgfone]

bt follows BEP and supports any protocol that can convert or map itself to IP or IP:PORT.

In order to do that, I have changed the address of KRPC and DHT from *net.UDPAddr to the interface net.Addr. And the connection of peer protocol is also the interface net.Conn.

If I2P cannot map itself to a VIRTUAL ip, it is hard for bt to support it.

[xgfone]

An address, for IPv6 with Port, has 144-bit, that's, 128+16.

[eyedeekay]

It's definitely possible for I2P to map to a virtual IP:Port, all of the existing I2P socket libraries have this capability. There's one in particular, https://github.com/eyedeekay/onramp which even offers a bittorrent "mode" where the conversion takes place automatically. onramp was actually largely borne of a desire to make a way to non-invasively modify Go bittorrent clients to readily work with I2P. In I2P the virtual port for bittorrent is always 6881, and the virtual IP is represented by a hash, and there is also a library to make this easier to work with: https://github.com/eyedeekay/i2pkeys

All it really takes in the case of go-bt(or almost any Go application) is the ability to pass an implementation of net.Addr to a Dialer that returns an I2P socket in the case of an outgoing connection, or return an implementation of net.Listener that listens on an I2P socket. So when you want a TCP-connection-like API a net.Conn ~= sam3.StreamSession, a TCP-listener-like API use net.Listener ~= sam3.StreamListener, and when you need a Datagram session a net.PacketConn ~= sam3.DatagramSession. So if you use interface types to represent your sockets, and those sockets are accessible to library users, then it's simple to replace IP:Port connections with I2P:Port connections. A really basic example which works in I2P-only mode is: https://github.com/xgfone/bttools/raw/115e2f0be3ff3f9bb83ea781b434bc78ed9d3e14/main.go and I've actually already used it pretty extensively.

The tricky part with go-bt anyway, is that originally you used concrete structures instead of interface types, and you use net.Dial directly and don't offer a way to substitute the underlying "Dial" function. As long as there's a way to do that, I can do everything required to adapt go-bt to I2P in onramp and library users/application developers can decide on what they want to use when they implement their applications.

[xgfone]

Yeah, you're right.

Based on L2P, now, you can implement a net.PacketConn and conversion between krpc.Addr and net.Addr to use the component dht, and implement a net.Conn to use the component peerprotocol.