0

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.

1

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

I don't think there is a "golden number" for waiting until the resource is available, it entirely depends on your use case, and it's why IPFS doesn't set any default timeout.

If you have a archive application that is mainly supposed to work in bad connectivity areas, it might be best to just not have any timeouts as people can then themselves decide when they waited enough for that video to show up.

On the other hand, if you have a chat-application that is supposed to be fast and what not, maybe waiting 5 seconds and then moving on might be the right decision.

In the end, it depends.

  • IPFS in hang eats some memory. When I do IPFS operations in parallel it locks down the node I am working on. Long time out and having running ipfs add <hash> in parallel seems like a not a good idea. If wish there were some kind of hash-map to check connectivity. @Victor Bjelkholm – alper Jun 19 '17 at 9:21
  • Suppose I have autonomous system and client submits a false IPFS hash, which will create the situation I mention. @Victor Bjelkholm – alper Jun 19 '17 at 9:22
  • 1
    Hm, I see. Maybe instead of doing ipfs object stat to get information about the object, you can do ipfs dht findprovs to see how many peers in the network that can provide the data for you. If this returns 0 peers after X seconds, assume the object does not exist. If it shows > 0 peers, it exists and you might just have to leave the get/cat running until you get it. – Victor Bjelkholm Jun 19 '17 at 11:19
  • That is very good idea. Is there any required time to obtain ipfs object stat's returned value or does it return right away? I mean in first try could return nothing in 10 minutes and after that could it return some value? The same question would be what might be the X seconds? @Victor Bjelkholm – alper Jun 19 '17 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.