From @JustinDrake on Tue Nov 22 2016 16:40:27 GMT+0000 (UTC)
Has there been measurements as to how fast an IPNS change propagates to the DHT. Are we talking <1s, <10s, <100s?
Copied from original issue: https://github.com/ipfs/faq/issues/194
From @whyrusleeping on Tue Nov 22 2016 17:27:45 GMT+0000 (UTC)
There are several factors that can affect the perceived speed of an IPNS update:
- publish time
- The time it takes to run
ipfs name publishon the full network, depending on your nodes connectivity this can range from milliseconds up to ten seconds in the worst case.
- The time it takes to run
- cache lifetime on resolvers
- Nodes cache ipns entries for a small period of time if they have resolved it recently, If they recently cached a record, and you update it, it might take longer for them to resolve the new entry (unless they use
ipfs name resolve --nocache)
- Nodes cache ipns entries for a small period of time if they have resolved it recently, If they recently cached a record, and you update it, it might take longer for them to resolve the new entry (unless they use
- dht crawl time for resolve
- Resolving an ipns entry means crawling the DHT to find enough records to give yourself certainty that the record you found is the correct one. If you have recently resolved this record, you are very likely already connected to all of the right peers and this will take a few RTTs. If you are running a resolve on a fresh node, you will have to find and connect to all the appropriate peers, which will take a bit longer.
All in all, a DHT based ipns update should take in the tens of seconds, much less if the involved nodes are well primed.
In the nearish future we will have the option of distributing ipns records over pubsub, allowing records to propogate reliably in just a few RTTs (or even a single RTT if the publish and resolver are nearby in the pubsub swarm).