validation - 是否有任何最佳时间来检查 ipfs-hash 是否存在？

Question

ipfs object stat :

'ipfs object stat' is a plumbing command to print DAG node statistics. is a base58 encoded multihash.

如果给定的哈希有效，它会返回一些信息(当且仅当共享节点的 ipfs daemon 开启时)。

$ ipfs object stat QmNd4PHGU8Z7fwbEvps5jvVscCDd5husnNgKpaDCfm1tpt
NumLinks: 0
BlockSize: 39
LinksSize: 2
DataSize: 37
CumulativeSize: 39

现在我尝试使用无效的散列或节点(共享 ipfsHash)的 ipfs daemon关闭:我观察到命令停止。

$ ipfs object stat QmNd4PHGU8Z7fwbEvps5jvVscCDd5husnNgKpaDCfm1t88 #invalid hash
#waits.

如果我输入无效的 has 到 ipfs object stat它暂停了。我能做到timeout N终止它:但我不确定我应该等多久。

timeout 30 ipfs object stat QmNd4PHGU8Z7fwbEvps5jvVscCDd5husnNgKpaDCfm1t88

总的来说，我只想检查给定ipfs-hash存在是为了让我检索它的信息。

[Q] 有什么最佳时间让我等到ipfs object stat <ipfsHash>吗？是否返回有效值？等待大约 30 秒是否足够？

请注意:我在欧洲的节点和美国的节点之间进行了尝试，第一次尝试花费了大约 120 秒。但是在我假设在这些节点之间生成路径路由之后，我的下一次尝试在相同节点之间使用不同的哈希值需要不到一秒钟的时间。这可能是什么原因？

感谢您宝贵的时间和帮助。

Answer 1

不能 100% 确定什么会导致这样的延迟，但我认为自 2017 年以来 DHT 已经有了很多改进。发生的事情是您的节点正在有效地查看并询问“谁拥有此 CID？”。一旦找到谁拥有 CID，它就会直接从该节点 p2p 检索它(或使用 p2p-circuit )。

我认为没有完美的“最佳时间”，所以我想你必须决定什么是你觉得可以接受的。如果您预计延迟最多“大约 120 秒”，那么 150-180 秒听起来应该比较合理。在 2021 年，我很少遇到像这样的大延迟，但如果数据仅在具有限制性 NAT 的节点上，这并非完全闻所未闻。我个人通常会在 30 多岁左右放弃，但如果我相对确定数据难以检索，我有时会让它无限期地尝试，直到我最终获得我正在寻找的数据。

至于为什么从同一节点检索后速度如此之快，您现在可能已经与它们对等，或者与它们对等的另一个节点检索了它们的数据并将其保存在它们的缓存中(例如网关例子)。因此，您的节点可能知道它们，并且可能知道它们声称拥有的 CID，因此它能够更快地查找和检索数据。