problem writing and reading using the DAG

[tobowers]

Version information:

[[constraint]] revision = "49cda78d23e6837df7697c07766b60fd422216b8" name = "github.com/ipsn/go-ipfs"

which maps to v0.4.17 in this repo

Type:

Bug?

Description:

https://github.com/QuorumControl/ipfsplay

This is really simple code that just adds a node and then tries to read it back in a different process. I have it succeed very rarely... maybe 1 in 60-70 runs. Upping the timeout doesn't seem to help.

The write process succeeds and can read the node back from itself. However, the read side doesn't get the node. Sometimes it will find providers (6 or 7 of them) but it still cannot actually get the node.

[Stebalien]

1. IPFS listens on port 4001 by default. Unfortunately, I'm not sure how to change this programmatically (without modifying a config, writing it to disk, and then loading it from disk). The issue here is that IPFS really hasn't been optimized for use as a library yet (it assumes a local "repo" with a config file): https://github.com/ipfs/go-ipfs/issues/5432
2. (1) means that all three of your nodes are listening on the same port. This is due to: https://github.com/ipfs/go-ipfs/issues/5431.
3. When using FindProviders like that, your node will almost always wait the entire timeout trying to find more providers. You should probably consider using FindProvidersAsync or just not doing anything (bitswap will do this for you).
4. Because you're timing out on the FindProviders call, the context is getting canceled which is tearing down your node.

You also shouldn't need the third "bootstrap" node, unless I'm missing something.

[Stebalien]

Closing in favor of the two new bugs I filed. Feel free to ask followups, I just want to keep this tracker as clean as possible (heh...).

[tobowers]

Thank you!

[tobowers]

We ran this code on two different laptops within a coworking space. We upped the timeout to 200 seconds and both nodes had bootstrapped with 4 nodes. However, we had the same result where the 2nd node (the reader) never gets the block.

[Stebalien]

You'll still need to fix point 3 (you're calling Get with an expired context) and will need to get rid of the "bootstrap" node that you're running before the actual node (this will take port 4001).

[Stebalien]

Hm. I noticed you have fixed that. And it still doesn't work? It works for me locally (after making ipfs listen on random ports).

[Stebalien]

Did the reader find a provider record for the writer? Can you try manually running two ipfs nodes and connecting them ipfs swarm connect just to make sure it isn't a firewall/network issue.

[tobowers]

I'm travelling so moving slowly here. Thanks for all your help so far! I'm trying to figure out the peer id inside my app. it's giving me really short PeerIDs which don't look like IPFS ids: "0x1634ff0"

getting them from:

        log.Infof("addresses: %v", node.PeerHost.ID().String)
        log.Infof("addresses: %v", node.Identity)

UPDATE: found it... it's the "pretty" function not "string"

[brandonwestcott]

Hi all, also jumping in here trying to get this to work, I've tried a few different setups to no avail yet:

Running two ipfs daemons does work locally fine. I spun up an ipfs daemon on my local box and published a object and was able to retrieve it inside a docker container running ipfs.

Attempted to follow that same pattern with https://github.com/QuorumControl/ipfsplay. Ran go run main.go -p on my local box to publish, however I'm unable to retrieve it inside a docker container running ipfs. Inside the container, running ipfs swarm connect to the ipfsplay go process does work, running ipfs id does provide the correct info & matching pubkey, and running ipfs ping also pongs back with very low latency. But then running ipfs cat for the published object just hangs.

[tobowers]

@Stebalien @brandonwestcott and I work together... could you show how you got it to work locally?