Is this right ? Is there anything I can do or does it actually take this long? I have read in some research that it is an inevitable problem with DHT.
My swarm list has over 110 peers connected
At this moment in time, 1 minute is about right. In fact I would say that’s on the quicker order of things, in the past I’ve usually had it take up to 1m30s.
Also 110 peers really isn’t that much when you consider the size of the IPFS network right now, however truth be told even having 1000 peers probably wouldn’t increase the time that much. The only option right now would be to use the --stream option that you’re using.
I have had the same experience with IPFS hosts on the internet (public IPs and connected to 600+ peers).
Here is a silly question, why does it take 1m to resolve? Is it due to the lack of peers? Something with the protocol? Or because it takes that long to find the host who can resolve it?
Cheers
-nb
@anarkrypto @nboeger This isn’t a problem with the DHT itself, as much as with the “algorithm” required to use the DHT to resolve IPNS records. The TLDR is that because of the chaotic nature of a DHT it’s very difficult/impossible to know that you have the “latest” version of IPNS data so the system keeps looking for a while until it can find enough records (16 by default, but configurable by a flag) to feel comfortable telling you that it’s found the latest version.
However, there’s also an ongoing effort to leverage libp2p PubSub to make sure we actually do know the latest IPNS record version in the network, and therefore can resolve records much faster (checkout the youtube video referenced by that GitHub issue if you want to see it in action).
By the way, if you use IPNS with PubSub today (ipfs daemon --enable-namesys-pubsub CLI docs) you can resolve updates to an IPNS record much more quickly than simply doing resolve again. While this doesn’t help you with the initial resolve, if you are updating your data frequently then it should help with that.
1 Like