I recently migrated my ipfs node from 0.4.23 to 0.6.0 and notice a difference in the peer connections management.
My setup is the following:
I’ve a bootstrap node (in 0.4.23) started with a private swarm key.
I create two extra ipfs node configured to bootstrap on the previous node with the same private swarm key.
When the two extra ipfs node were in 0.4.23, I could see by executing ipfs swarm peers command that after a while, both nodes get connected to each other.
With 0.6.0, the nodes doesn’t get connected. However, if I do a ipfs dht findpeer with the peerID of the second node, the peer is found and they get connected together.
The issue for me is that I use the output of ipfs swarm peers to discover the nodes on my private network. It sounds like an acceptable way of implementing discovery to me as my network will keep a ‘low’ number of peers ( < HighWater value in configuration file). Obviously, if connections are not automatically done anymore between peers of a given swarm, it’ll not work anymore. Do I have to implement a proper dht crawler ?
Thanks for your help
The old DHT logic used to search pretty much the entire network on every query. That’s why you ended up connecting to all nodes. Unfortunately, this obviously doesn’t scale well.
If you want all nodes in the network to connect, you can probably use pubsub. Just have all peers subscribe to the same topic. I’m not sure if that’ll give you full connectivity, but it will get close for small networks.
Alternatively, you can use content routing:
- Have all nodes “provide” (
ipfs dht provide X) a well-known CID. (where X is the CID).
- Have all nodes connect to all providers of X (connect to all peers found by
ipfs dht findprovs X).
Thanks for your suggestions, I’ll try that ! The content routing solution sound like a good work around.