Added a file - but it's not accessible on gateway

Probably we need to open a GitHub issue to investigate more!

Hi! I’m on the go-ipfs team and work on the data transfer subsystem Bitswap (though fairly recently). I’d be happy to provide some assistance on the slowness vis a vis downloading. I’d love to get some specifics about your setup and then maybe we can go ahead and file a Github issue if there if it’s a bug in the code.

Just curious are you guys both running IPFS 0.4.18 (the most recent released version)? Are either of you building from source? (i.e. master on the IPFS github repo)?

I tried replicating on my machine but right now I have the same connection issues as you started off with and can’t diagnose the slowness as a result. (i.e. @john1deer I can’t ping your machine - I can ping the relay you gave but it won’t let me swarm connect to your peer).


I did some tests here: Proposal: Peer Hint URI scheme

I’m happy to help though. :slight_smile:

I have 0.4.18 yes. Not building from source.

0.4.18 (not source)

Restarted daemon just now (with everything turned on):
$ ipfs daemon
Initializing daemon…
go-ipfs version: 0.4.18-
Repo version: 7
System version: amd64/darwin
Golang version: go1.11.1
Swarm listening on /ip4/
Swarm listening on /ip4/
Swarm listening on /ip4/
Swarm listening on /ip4/
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /p2p-circuit
Swarm announcing /ip4/
Swarm announcing /ip4/
Swarm announcing /ip6/::1/tcp/4001
API server listening on /ip4/
Gateway (readonly) server listening on /ip4/
Daemon is ready

Sorry for slow reply. I’d be include to wait for 0.4.19 to get published. BS has undergone extensive changes that should mitigate this kind of issue.

I’m assuming BS = BitSwap?

The issue here seems to be NAT traversal, although this could be fixed by adding a block “relay” functionality to BitSwap (if I have a route to a block on a peer’s wantlist - I can fetch it for the peer).