3

ipfs object stat:

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

If given hash is valid, it returns some information (if and only if shared node's ipfs daemon is on).

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

Now I try it with an invalid hash or node (which shares the ipfsHash)'s ipfs daemon is off: I observe that the command halts.

$ ipfs object stat QmNd4PHGU8Z7fwbEvps5jvVscCDd5husnNgKpaDCfm1t88 #invalid hash
#waits.

If I enter an invalid has into ipfs object stat it pauses. I can do timeout N to terminate it: But I am not sure how long should I wait.

timeout 30 ipfs object stat QmNd4PHGU8Z7fwbEvps5jvVscCDd5husnNgKpaDCfm1t88

Overall, I just want to check does given ipfs-hash exists for me to retrieve its information.

[Q] Is there any optimal time for me to wait until ipfs object stat <ipfsHash> returns a valid value or not? Would around 30 seconds to wait be enough?

Please note that: I tried between node in Europe and node in States, it took around 120 seconds on first try. But after I assume a path route is generated between those nodes, my next try with different hash between same nodes takes less than a second. What might be the reason for this?

Thank you for your valuable time and help.

4

1 回答 1

0

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

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

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

于 2021-07-09T03:28:10.387 回答