Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
wongnoubo opened this issue Mar 27, 2019 · 5 comments
Closed

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

wongnoubo opened this issue Mar 27, 2019 · 5 comments

Comments

@wongnoubo
Copy link

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
Copy link

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
Copy link
Member

There are likely a few issues here:

  1. 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.
  2. Our gateways are a bit slow at the moment and overloaded with requests.

@wongnoubo
Copy link
Author

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
Copy link

dkasak commented Mar 31, 2019

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
Copy link
Member

Stebalien commented Apr 1, 2019

There's a delay because we have to wait for DHT to come online. We need to fix libp2p/go-libp2p-kad-dht#193 and/or libp2p/go-libp2p-kad-dht#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 (#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants