I don't know "ipfs daemon" command has worked

wongnoubo commented 5 years ago

Version information:

go-ipfs version: 0.4.19- Repo version: 7 System version: amd64/windows Golang version: go1.11.5

Type:

Description:

I add a picture to my local ipfs node by git bash. $ ipfs add index.png Then I got: added QmXWU34mbFLHdSZAisadaFkDitEMHynJHjXTHYPeTLXXdA index.png 50.21 KiB / 50.21 KiB 100.00%

Then I want to visit the picture by public gateway,So I run the command "ipfs daemon"

Initializing daemon... go-ipfs version: 0.4.19- Repo version: 7 System version: amd64/windows Golang version: go1.11.5 Swarm listening on /ip4/127.0.0.1/tcp/4001 Swarm listening on /ip4/169.254.103.92/tcp/4001 Swarm listening on /ip4/169.254.237.169/tcp/4001 Swarm listening on /ip4/192.168.0.1/tcp/4001 Swarm listening on /ip4/192.168.1.38/tcp/4001 Swarm listening on /ip6/2001:0:2851:78dd:8e3:cf3d:2594:eed7/tcp/4001 Swarm listening on /ip6/::1/tcp/4001 Swarm listening on /p2p-circuit Swarm announcing /ip4/127.0.0.1/tcp/4001 Swarm announcing /ip4/169.254.103.92/tcp/4001 Swarm announcing /ip4/169.254.237.169/tcp/4001 Swarm announcing /ip4/192.168.0.1/tcp/4001 Swarm announcing /ip4/192.168.1.38/tcp/4001 Swarm announcing /ip4/192.168.2.2/tcp/10154 Swarm announcing /ip6/2001:0:2851:78dd:8e3:cf3d:2594:eed7/tcp/4001 Swarm announcing /ip6/::1/tcp/4001 API server listening on /ip4/127.0.0.1/tcp/5001 WebUI: http://127.0.0.1:5001/webui Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080 Daemon is ready

I wait it work about 2 minutes and I visit it by the link "https://ipfs.io/ipfs/QmXWU34mbFLHdSZAisadaFkDitEMHynJHjXTHYPeTLXXdA" It's bad that the link doesn't work.I got "504 Gateway Time-out". I am in the Southern China, I can watch Youtube by my ssr tools. Any help will be appreciated!

reardenlife commented 5 years ago

The link you posted is working right now.

What you encountering is a problem of decentralized/p2p systems in general. They are unstable and unreliable. The only solution I came up with is to wrap every action of your service/app as a job in a job scheduler ( something like agenda, perhaps? https://github.com/agenda/agenda ). So that you can save the command of say, a file retrieval, into DB and continuosly run it until success.

Stebalien commented 5 years ago

There are likely a few issues here:

You're adding the file in "offline" mode (i.e., you haven't started the daemon). When you do that, we don't tell the network that you have the file. When you start the daemon, go-ipfs will then tell the network that you have the file but it waits a few (5?) minutes before it does so.
Our gateways are a bit slow at the moment and overloaded with requests.

wongnoubo commented 5 years ago

Thanks you! I use online gateway and I wait for it about 1 hour .Then I can visit my file via links.It is clear that the gateway is a little slow.

dkasak commented 5 years ago

When you start the daemon, go-ipfs will then tell the network that you have the file but it waits a few (5?) minutes before it does so.

What is the reason for this delay? Could it be made shorter?

Stebalien commented 5 years ago

There's a delay because we have to wait for DHT to come online. We need to fix https://github.com/libp2p/go-libp2p-kad-dht/issues/193 and/or https://github.com/libp2p/go-libp2p-kad-dht/issues/295.

We could probably make this shorter, but it won't help much in most cases. The delayed system is actually the automatic re-provider system that walks over every file you have, announcing every block. This takes a long time.

We have some work in progress (https://github.com/ipfs/go-ipfs/pull/6141) that will keep an on-disk queue of things to be provided. Once we implement that and the DHT issue, this should be fixed.

ipfs / kubo