Sometimes IPFS can't find the file

[dlnuwlx]

Hi experts
I have two PCs with external ip （node A , B）
A: ipfs init & ipfs daemon & ipfs add "file"
B: ipfs init & ipfs daemon & ipfs get "hash of file"
Node B hungs and can't download the file, but if run "ipfs swarm connect(A->B or B->A)" , B can download the file. why node B can't find the file by DHT net? Is "ipfs swarm connect” a must?

Tips: if run "ipfs swarm peers" in A or B, I can see many peers, so bootstraps is working!

[dlnuwlx]

update!
Even if run "ipfs swarm connect(A->B or B->A)", sometimes B download the file(about 1M) more than three minutes

[magik6k]

Which version are you using? (ipfs version --all).

[dlnuwlx]

Which version are you using? (ipfs version --all).

go-ipfs version: 0.4.17-
Repo version: 7
System version: amd64/linux
Golang version: go1.10.3

[eingenito]

Hey @dlnuwlx did you solve this problem? ipfs swarm connect shouldn't be required between two hosts sharing files. But it can speed up the time it takes ipfs to begin transferring data. If your nodes are already connected (like via swarm connect) the fetching host won't need to ask for records from the DHT to start retrieving the data; they can begin transferring data immediately.

Can you try fetching provider records directly from the DHT by running ipfs dht findprovs [hash of file]? That command should return the peer IDs of one or more hosts that have advertised themselves as providers of that hash in the DHT. If that command times out then it indicates a problem and would prevent your (unconnected) ipfs instance running get from ever learning of the providing ipfs instance, and therefore no file transfer.

[dlnuwlx]

Hi eingenito
Thanks, Got it,
I found that "ipfs get HASH" was slower than "https://ipfs.io/ipfs/HASH" by browser, "https://ipfs.io" is also a ipfs node as a gateway, right?

[eingenito]

Yes - ipfs.io is a public ipfs gateway. If you can see unique content you've published there it probably means that your providing node (the node you invoked ipfs add on) successfully published a provider record and its peer information to the DHT. It also means that the gateway was able to receive that data from your node via bitswap. That would seem to indicate that there's an issue with your ipfs get node. If the gateway works for your use case that's great.

I'm gonna close your issue, but feel free to reopen if you have questions. Actually you may get better turnaround if you post questions to https://discuss.ipfs.io/ which also makes them more accessible for others searching for information.

[kikoncuo]

Same problem when testing in a private swarm.

I have nodes 1, 2 and 3.

Node 1 is connected to 2, node 2 is connected to 3.

1 can't access files from 3 unless 2 has them and vice-versa.

go-ipfs version: 0.4.22-
Repo version: 7
System version: amd64/windows
Golang version: go1.12.7

[Stebalien]

@kikoncuo Please file a new issue.

[kikoncuo]

Done I´ve changed the question a bit due to some experiments, I think I found the problem #6711