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

【问题标题】：Is there any optimal time to check ipfs-hash exist or not?是否有任何最佳时间来检查 ipfs-hash 是否存在？
【发布时间】：2021-07-09 11:28:10
【问题描述】：

ipfs object stat:

'ipfs object stat' 是一个打印 DAG 节点统计信息的管道命令。是一个 base58 编码的多重哈希。

如果给定的哈希是有效的，它会返回一些信息（当且仅当共享节点的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.

如果我在ipfs object stat 中输入无效的has，它会暂停。我可以通过timeout N 终止它：但我不确定我应该等待多长时间。

timeout 30 ipfs object stat QmNd4PHGU8Z7fwbEvps5jvVscCDd5husnNgKpaDCfm1t88

总的来说，我只想检查是否存在 ipfs-hash 以供我检索其信息。

[Q] 是否有最佳时间等待ipfs object stat <ipfsHash> 返回有效值？等待大约 30 秒就够了吗？

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

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

【问题讨论】：

标签： validation hash ipfs

【解决方案1】：

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

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

至于为什么从同一个节点进行检索后速度如此之快，您现在要么与他们对等（可能），要么与他们对等的另一个节点检索到他们的数据并将其保存在缓存中（如网关例子）。因此，您的节点可能知道它们以及它们声称拥有的 CID，因此它能够更快地找到和检索数据。

【讨论】：