search

ipfs / kubo

An IPFS implementation in Go
https://docs.ipfs.tech/how-to/command-line-quick-start/
Other
16.19k stars 3.02k forks source link

DHT implementation #12

Closed toqueteos closed 10 years ago

toqueteos commented 10 years ago

dht.go links to https://github.com/jbenet/node-ipfs/blob/master/submodules/ipfs-dht/index.js which I'm currently porting from JS to Go but there are some quirks on the JS code.

May I ask you what is supposed to be a DHTStream? Currently is not implemented and the closest thing I could find is swarm.Conn.

Also there's issues with peer.ID being a multihash.Multihash which it's underlying type is []byte which can't be used as map keys and you are trying to use it that way, I already informed about this on #8.

You should focus on just one implementation until is finished so other people can port to other languages. Preferably the Go one because it's a static one.

toqueteos commented 10 years ago

I forgot this: I know there's util.Key which btw seems like an unnecessary abstraction, why don't just use string as key and avoid any future import cycles?

// Copied from util/util.go

// Key is a string representation of multihash for use with maps.
type Key string
whyrusleeping commented 10 years ago

I agree on it being a somewhat unecessary abstraction, but I think in the future we might want to have something around the key type for calculating distances for the kademlia dht. They are going to need to be able to be Xor'ed and compared as integers in order to do proper routing.

Also, I was thinking that a DHTStream was going to have to be a type we define to manage any sort of connection (be it TCP, UDP, WebSock, serial port, smoke signals, etc) and define at least a simple "Send Message" method on it for the base dht communication.

jbenet commented 10 years ago

Hey guys, this weekend (7/24-7/26) I only have intermittent internet access-- but I'll respond to issue comments as soon as I can.

jbenet commented 10 years ago

May I ask you what is supposed to be a DHTStream? Currently is not implemented and the closest thing I could find is swarm.Conn.

DHTStream is implementing according to a node pattern of creating everything according to streams. this is not the same for Go, so don't expect it to be similar at all. I still need to layout a block diagram of how the code here works, but the idea is to use swarm and send swarm.Message instances to the right peers. it handles muxing to many peers.

I know there's util.Key which btw seems like an unnecessary abstraction, why don't just use string as key and avoid any future import cycles?

Because type safety. I'd like the compiler to know when a Key is a key and not just a random string. Also, as @whyrusleeping mentions, it becomes easier to expand the interface.

I was thinking that a DHTStream was going to have to be a type we define to manage any sort of connection

Look at the swarm package.

The DHT should implement the Routing interface already laid out. It can spawn its own goroutines, but should a swarm.Swarm instance passed to it to do all network comm. (just send swarm.Messages through the swarm.Swarm.Chan thing.

whyrusleeping commented 10 years ago

Referencing Pull Request #25

whyrusleeping commented 10 years ago

Closing. Dht is (in my opinion) rather implemented.