ECONNREFUSED 127.0.0.1:5002

[Willzyc]

Hello,

I tried to start developing with IPFS but I cannot get it working with the information provided by the documentation.

What I tried was starting a IPFS node and access it via the IPFS-API

My Script for starting the node is:

const gulp = require('gulp');
const IPFS = require('ipfs');

gulp.task('ipfs', function() {
    const node = new IPFS();
});

The terminal output was:
[14:27:56] Using gulpfile ~/Development/client/gulpfile.js
[14:27:56] Starting 'ipfs'...
[14:27:56] Finished 'ipfs' after 19 ms
Swarm listening on /ip4/127.0.0.1/tcp/4003/ws/ipfs/QmdKNWzEgeKdxrsgPu16U8fvAWU9AC8DjuAPoENAGSmfhC
Swarm listening on /ip4/127.0.0.1/tcp/4002/ipfs/QmdKNWzEgeKdxrsgPu16U8fvAWU9AC8DjuAPoENAGSmfhC
Swarm listening on /ip4/192.168.2.104/tcp/4002/ipfs/QmdKNWzEgeKdxrsgPu16U8fvAWU9AC8DjuAPoENAGSmfhC
Swarm listening on /ip4/10.8.8.2/tcp/4002/ipfs/QmdKNWzEgeKdxrsgPu16U8fvAWU9AC8DjuAPoENAGSmfhC

And then the API call with this script (I opened a new terminal, so the ipfs node keeps running):

const gulp = require('gulp');
const ipfsAPI = require('ipfs-api');

gulp.task('ipfs:api', function() {
    const ipfs = ipfsAPI('/ip4/127.0.0.1/tcp/5002');

    ipfs.add(new Buffer('Hello World'), (error, files) => {
        if (error) {
            console.log(error);
        } else {
            console.log(files);        
        }
    });
});

Here I get the error:

{ Error: connect ECONNREFUSED 127.0.0.1:5002
at Object.exports._errnoException (util.js:1050:11)
at exports._exceptionWithHostPort (util.js:1073:20)
at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1093:14)
code: 'ECONNREFUSED',
errno: 'ECONNREFUSED',
syscall: 'connect',
address: '127.0.0.1',
port: 5002 }

The same with port 5001

I dont know if its an ipfs or ipfs-api issue, did I missed anything crucial?

I am running on Ubuntu 16.04

[daviddias]

@Willzyc you are trying to connect to an IPFS instance (aka not a daemon). To Start an IPFS daemon use http://github.com/ipfs/js-ipfsd-ctl/

[musicsmithnz]

@Willzyc

Have you managed to solve your problem yet?
You can go here to download a daemon ipfs daemon install

then

${package_name} is the name of the package you download, which will depend on your architecture: the 32 or 64 bit version.
init sets up a place to store the files received by the API daemon.
ipfs config Addresses.API /ip4/0.0.0.0/tcp/5002 makes your daemon listen globally, it's actually unsafe to do this without setting up authentication, as it allows anyone globally to add data to your computer. Choose whether you want this or not.
The HTTP Headers is to allow cross origin requests so you can make requests from a browser. Again, you may or may not want to do this.
ipfs daemon & is to start the daemon in the background

tar xvzf ${package_name}
cd ${package_name}
./install.sh
ipfs init
ipfs config Addresses.API /ip4/0.0.0.0/tcp/5002
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Origin '["*"]'
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Methods '["GET", "POST"]'
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Headers '["Authorization"]'
ipfs config --json API.HTTPHeaders.Access-Control-Expose-Headers '["Location"]'
ipfs config --json API.HTTPHeaders.Access-Control-Allow-Credentials '["true"]'
ipfs daemon &

[kdunn926]

Would someone be able to help me understand the distinction between starting a js-ipfs instance and a js-ipfsd-ctl daemon? I get that the former is implemented and run in Javascript and the latter is Javascript invoking the Go binary on the filesystem, but what are the functional differences? e.g. Is it possible to interact with the js-ipfs instance from outside the Javascript console using curl?

[Mr0grog]

Would someone be able to help me understand the distinction between starting a js-ipfs instance and a js-ipfsd-ctl daemon?

Ah! An IPFS instance (whether in Go or JS) is a library or program that is able to communicate with other IPFS instances (or daemons, or whatever) using bitswap, to trade data back and forth.

An IPFS daemon is a specific program that is packaged with both go-ipfs and js-ipfs that runs an IPFS instance, an HTTP API server, and an HTTP gateway server together, so you can control it externally and use it to load data in a browser (by browsing to the gateway).

If you are running IPFS inside your own program as a package or library, you probably just want to run an instance (because you don’t need to control it externally). That’s what you get when you:

const IPFS = require('ipfs')
const instance = new IPFS({ /* options */ })

BUT you can also start the HTTP API server or the gateway server in your process if you like, too (although it would probably be unusual).

…a js-ipfsd-ctl daemon? I get that the former is implemented and run in Javascript and the latter is Javascript invoking the Go binary…

One important thing to understand here is that js-ipfsd-ctl can run a lot of things, not just the go-ipfs daemon! See the type option in the docs for more, but you can launch:

• A go-ipfs daemon as a sub-process (an entirely separate program that your program controls)
• A js-ipfs daemon as a sub-process
• A js-ipfs instance directly in your process instead of as a sub-process (this is the proc type)

So js-ipfsd-ctl can actually launch a daemon or just an instance.

[Mr0grog]

Also, to clarify, when interacting with a daemon using curl, you’re using the HTTP API server. So an instance by itself won’t be something you can control with curl, but a daemon is.

[kdunn926]

Very helpful and thorough explanation!

[alanshaw]

@Willzyc has that answered you question?

[daviddias]

Reopen if needed :)