有没有检查ipfs-hash的最佳时间？

Question

ipfs object stat：

  

'ipfs object stat'是用于打印DAG节点统计信息的管道命令。    是base58编码的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.

如果我输入无效的ipfs object stat，它会暂停。我可以timeout N来终止它：但我不确定我应该等多久。

timeout 30 ipfs object stat QmNd4PHGU8Z7fwbEvps5jvVscCDd5husnNgKpaDCfm1t88

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

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

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

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

Answer 1

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

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

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