semkodev / nelson.cli Goto Github PK

View Code? Open in Web Editor NEW

129.0 22.0 20.0 329.27 MB

WE HAVE MOVED TO A NEW REPOSITORY

Home Page: https://gitlab.com/semkodev/nelson.cli

License: ISC License

JavaScript 85.47% Python 14.42% Dockerfile 0.11%

p2p iota iri

nelson.cli's People

Contributors

Stargazers

Watchers

Forkers

rosstimson iotfab h3npi nuriel77 sreeraj-krishnan lra rajivshah3 duckybsd yet-another-account 831jsh sofwerx testtkxxd prizz stanleyatiota longfld xiongzm dad1x luizcarlosleao

nelson.cli's Issues

/usr/local/bin/nelson: line 1: use strict: command not found

Cannot run nelson on Ubuntu 16.04 after following global installation steps in README
node -v: 9.1.0

nelson --neighbors nelson1.carriota.com/14600 nelson2.carriota.com/14600
/usr/local/bin/nelson: line 1: use strict: command not found
/usr/local/bin/nelson: line 3: syntax error near unexpected token `('
/usr/local/bin/nelson: line 3: `var ini = require('ini');'

Static neighbors removed by nelson?

Static neighbors from iri.ini file get removed if nelson.cli is running prior to starting iri.

For this not to happen I'm making sure to stop Nelson prior to restarting iri and starting nelson again after that.

Others in discord have reported the same behavior.

Basic Info

iri playbook install

Operating System: Ubuntu 16.04LTS
Node (npm) Version: 8.10.0
IRI Version: 1.4.2.2
Nelson version: 0.4.0

Still something wrong with adding/removing neighbors

Hey @romansemko, last time I found out that static neighbors were removed in like 0.3.1 or so.. Since then I have been monitoring the neighbor count closely. I observed the same two problems on my 3 nodes:

Expected behaviour

Amount of added neighbors should not violate the settings
When closing nelson it should remove all previously added neigbhbors

Actual behaviour

Having 2 static neighbors and setting nelson to 4 / 3 (in/out) there are sometimes up to 13 neighbors reported by iri
I often end up with 3 sometimes up to 5 neighbors after closing nelson. Substracting my 2 static neighbors, that leaves me with 1 to 3 added neighbors (by nelson) that it didn't remove properly on exit

Steps to reproduce

Start iri and nelson
Wait until sync
Look at neighbor count in iri (see that it's not following nelsons config)
Close nelson
Look at neighbor count in iri (see that you have more neighbors than before starting nelson)

Basic Info

Operating System: Ubuntu 17.10 (x64)
Node (npm) Version: node: 8.9.4 (npm: 5.6)
IRI Version: 1.4.1.6
Nelson version: 0.3.16

Confirmed transactions do not spread from the Tangle to my node

Expected behaviour

Balance should be updated once a transaction is confirmed.

Actual behaviour

Address balance is 0 on my node whereas address balance is 1 on bitfinex node.

Steps to reproduce

Launch your node
Send a iota to an address
Once the transaction is confirmed, compare the balance of the adress using bitfinex node and on yours

It has been more than 24 hours since my transaction was confirmed.

Basic Info

Operating System: Linux
Node (npm) Version: last docker version
IRI Version: last docker version
Nelson version: last docker version

How do you use a static IP address with Nelson

Is it in the config file? Also where is the config file located.

How to use nelson behind kubernetes load balancer?

The only way to expose port on kubernetes is through a load balancer so I believe peers aren't able to connect to by node? How can I let the other nodes what ip address to use when connecting to my nelson node?

Connection errors running Nelson without neighbours

Ubuntu 16.04
node -v: 9.1.0

reproduce:

tried to use nelson, but failed with error as reported in #2
node ./src/nelson.js

Gives an output:

node ./src/nelson.js
1512730999739 16600::LIST  db and default peers loaded
1512730999741 16600::NODE  server created...
1512730999742 16600::HEART Cycle/epoch intervals: 60 300
1512730999742 16600::HEART new personality f 722ab289eb1a6b044fdfe2640085f15e341abcb64fb00f26604b12ffcde5cd93e0e885315e0cb8511f3a1115ae59d23b
1512730999743 16600::NODE  connecting peer http: null
1512730999745 16600::NODE  connecting peer https: null
1512730999746 16600::NODE  initialized!
1512730999748 16600::LIST  updated peer http::null { hostname: 'http:',
  ip: null,
  port: null,
  TCPPort: null,
  UDPPort: 14600,
  seen: 1,
  connected: 0,
  tried: 0,
  weight: 1,
  dateTried: null,
  dateLastConnected: null,
  isTrusted: true }
1512730999750 16600::LIST  updated peer https::null { hostname: 'https:',
  ip: null,
  port: null,
  TCPPort: null,
  UDPPort: 14600,
  seen: 1,
  connected: 0,
  tried: 0,
  weight: 1,
  dateTried: null,
  dateLastConnected: null,
  isTrusted: true }
1512730999755 16600::NODE  closing connection { Error: getaddrinfo ENOTFOUND http http:80
    at errnoException (dns.js:55:10)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:97:26)
  code: 'ENOTFOUND',
  errno: 'ENOTFOUND',
  syscall: 'getaddrinfo',
  hostname: 'http',
  host: 'http',
  port: 80 }
1512730999756 16600::NODE  removing neighbor http: null
1512730999756 16600::NODE  removing neighbors
1512730999756 16600::IRI   Neighbors removed [ 'http://http::null' ]
1512730999757 16600::NODE  closing connection 1006
1512730999757 16600::NODE  removing neighbor http: null
1512730999757 16600::NODE  removing neighbors
1512730999757 16600::IRI   Neighbors removed [ 'http://http::null' ]
1512730999758 16600::NODE  closing connection { Error: getaddrinfo ENOTFOUND https https:80
    at errnoException (dns.js:55:10)
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (dns.js:97:26)
  code: 'ENOTFOUND',
  errno: 'ENOTFOUND',
  syscall: 'getaddrinfo',
  hostname: 'https',
  host: 'https',
  port: 80 }
1512730999758 16600::NODE  removing neighbor https: null
1512730999758 16600::NODE  removing neighbors
1512730999758 16600::IRI   Neighbors removed [ 'http://https::null' ]
1512730999758 16600::NODE  closing connection 1006
1512730999742 16600::HEART new personality f 722ab289eb1a6b044fdfe2640085f15e341abcb64fb00f26604b12ffcde5cd93e0e885315e0cb85[58/4750]
ae59d23b
1512730999743 16600::NODE  connecting peer http: null
1512730999745 16600::NODE  connecting peer https: null
1512730999746 16600::NODE  initialized!
1512730999748 16600::LIST  updated peer http::null { hostname: 'http:',
  ip: null,
  port: null,
  TCPPort: null,
  UDPPort: 14600,
  seen: 1,
  connected: 0,
  tried: 0,
  weight: 1,
  dateTried: null,
  dateLastConnected: null,
  isTrusted: true }
1512730999750 16600::LIST  updated peer https::null { hostname: 'https:',
  ip: null,
  port: null,
  TCPPort: null,
  UDPPort: 14600,
  seen: 1,
  connected: 0,
  tried: 0,
  weight: 1,
  dateTried: null,
  dateLastConnected: null,
  isTrusted: true }
1512730999755 16600::NODE  closing connection { Error: getaddrinfo ENOTFOUND http http:80
... continues forever

Running isMaster with outgoingMax set makes Nelson ignore the neighbour limits

Expected behaviour

Maximal neighbours connected should stay at 11 +/- 1.

Actual behaviour

Over 3o neighbours are added!

Steps to reproduce

Run nelson as entry node with isMaster and outgoingMax set.

Basic Info

Operating System: Linux
Node (npm) Version: 6+
IRI Version: 1.4.1.4
Nelson version: 0.2.4

Nelson Info

Epoch: doesn't matter
Cycle: doesn't matter
Connected peers: 28

Invalid Response: Error: read ECONNRESET / Promise rejection

Expected behaviour

No exception occuring ;-)
Recoginzed unsynced node. Found that Nelson exception was the cause.

Actual behaviour

Error log of pm2

Error: read ECONNRESET
    at _errnoException (util.js:1022:11)
    at TCP.onread (net.js:615:25)
You have triggered an unhandledRejection, you may have forgotten to catch a Promise rejection:
Error: Invalid Response: Error: read ECONNRESET
    at _errnoException (util.js:1022:11)
    at TCP.onread (net.js:615:25)
    at Object.invalidResponse (/usr/lib/node_modules/nelson.cli/node_modules/iota.lib.js/lib/errors/requestErrors.js:5:12)
    at makeRequest.prepareResult (/usr/lib/node_modules/nelson.cli/node_modules/iota.lib.js/lib/utils/makeRequest.js:285:24)
    at exports.XMLHttpRequest.request.onreadystatechange (/usr/lib/node_modules/nelson.cli/node_modules/iota.lib.js/lib/utils/makeRequest.js:71:25)
    at exports.XMLHttpRequest.dispatchEvent (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:591:25)
    at setState (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:610:14)
    at exports.XMLHttpRequest.handleError (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:532:5)
    at ClientRequest.errorHandler (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:459:14)
    at emitOne (events.js:116:13)
    at ClientRequest.emit (events.js:211:7)
    at Socket.socketErrorListener (_http_client.js:387:9)
Error: read ECONNRESET
    at _errnoException (util.js:1022:11)
    at TCP.onread (net.js:615:25)
You have triggered an unhandledRejection, you may have forgotten to catch a Promise rejection:
Error: Invalid Response: Error: read ECONNRESET
    at _errnoException (util.js:1022:11)
    at TCP.onread (net.js:615:25)
    at Object.invalidResponse (/usr/lib/node_modules/nelson.cli/node_modules/iota.lib.js/lib/errors/requestErrors.js:5:12)
    at makeRequest.prepareResult (/usr/lib/node_modules/nelson.cli/node_modules/iota.lib.js/lib/utils/makeRequest.js:285:24)
    at exports.XMLHttpRequest.request.onreadystatechange (/usr/lib/node_modules/nelson.cli/node_modules/iota.lib.js/lib/utils/makeRequest.js:71:25)
    at exports.XMLHttpRequest.dispatchEvent (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:591:25)
    at setState (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:610:14)
    at exports.XMLHttpRequest.handleError (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:532:5)
    at ClientRequest.errorHandler (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:459:14)
    at emitOne (events.js:116:13)
    at ClientRequest.emit (events.js:211:7)
    at Socket.socketErrorListener (_http_client.js:387:9)
You have triggered an unhandledRejection, you may have forgotten to catch a Promise rejection:
undefined

Steps to reproduce

unknown / random occurance

Basic Info

Operating System:
Ubuntu 16.04.3 LTS
Node (npm) Version:
v8.9.4
IRI Version:
1.4.2.4
Nelson version:
0.4.0

Nelson Info

Epoch: default settings
Cycle: default settings
Connected peers: default settings

Feature Request: testnet support

Hello,

it would be great if nelson would also have support for the IOTA testnet.

Best regards
Matthias

Why does the docker scripts require network_mode: "host"? This prevents the bound ports from being exposed

I have tried using docker-compose and a container link in order to run but it seems like it connects initially but them it starts to error out saying "IRI gone... closing all Nelson connections" even though IRI is running fine and I can query through curl either remotey or on the local box. When I use network_mode: "host" it works but then I am not able to connect to IRI from external to the running box.

I am receiving this error:

Error: Request Error: COMMAND getNeighbors is not available on this node
at Object.requestError (C:\Files\Projects\IOTA\Nelson\nelson.cli\node_modules\iota.lib.js\lib\errors\requestErrors.js:11:12)
at makeRequest.prepareResult (C:\Files\Projects\IOTA\Nelson\nelson.cli\node_modules\iota.lib.js\lib\utils\makeRequest.js:168:24)
at exports.XMLHttpRequest.request.onreadystatechange (C:\Files\Projects\IOTA\Nelson\nelson.cli\node_modules\iota.lib.js\lib\utils\makeRequest.js:62:25)
at exports.XMLHttpRequest.dispatchEvent (C:\Files\Projects\IOTA\Nelson\nelson.cli\node_modules\xmlhttprequest\lib\XMLHttpRequest.js:591:25)
at setState (C:\Files\Projects\IOTA\Nelson\nelson.cli\node_modules\xmlhttprequest\lib\XMLHttpRequest.js:610:14)
at IncomingMessage. (C:\Files\Projects\IOTA\Nelson\nelson.cli\node_modules\xmlhttprequest\lib\XMLHttpRequest.js:447:13)
at emitNone (events.js:91:20)
at IncomingMessage.emit (events.js:186:7)
at endReadableNT (_stream_readable.js:974:12)
at _combinedTickCallback (internal/process/next_tick.js:74:11)

docker-compose.yml

version: '2'

services:
iota:
image: iotaledger/iri:latest
ports:
- "14265:14265"
- "14600:14600"
- "15600:15600"
- "14777:14777/udp"
- "15777:15777"
volumes:
- iota.ini:/iri/iota.ini
- iota:/iri
- iota_data:/iri/data
- iota_conf:/iri/conf

nelson:
image: romansemko/nelson
command: -r iota -i 14265 -u 14600 -t 15600 --neighbors "mainnet.deviota.com/16600 mainnet2.deviota.com/16600 mainnet3.deviota.com/16600 iotairi.tt-tec.net/16600"
ports:
- "18600:18600"
depends_on:
- iota
links:
- iota:iota

volumes:
iota:
iota.ini:
iota_data:
iota_conf:

IRI connection retry attempts before error / quit

Working on getting Nelson working alongside IRI using Docker as Docker seemed to be the preferred route to take for deployments during early discussions in Slack.

I am currently experimenting with a Docker Compose file for setting up the entire stack with a single command however, Nelson throws and error and quits as there is a slight race condition and it tries to connect to IRI before the IRI container is ready. I can workaround this by simply running docker-compose start nelson slightly after the initial docker-compose up but this isn't very user friendly. It would be great if Nelson could simply try again a couple of times before erroring out. Is that a possibility?

If you would prefer not to implement this there are a few possible workarounds:

Option 1

Add a healthcheck to the IRI service, in Docker Compose you can do something like:

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost"]
  interval: 1m30s
  timeout: 10s
  retries: 3

The 'official' IRI Docker images does not have curl or anything else suitable to carry out a check so we'd need to create a custom image which ideally I'd like to avoid. Also, this is a Docker Compose thing and would not help improve matters if you were deploying containers via some other method.

Option 2

Amend the Nelson Dockerfile to change it to start via a small shell script that wraps the whole thing in a loop, something like:

while ! nc -z iri 14265; do sleep 3; done

I think option 2 is probably the better of the 2 here if you do not wish to make the code handle this. I'd love to hear your thoughts. This sort of thing is a common issue with Docker deployments, some further info and ideas can be seen here: https://docs.docker.com/compose/startup-order/

Increasing CPU usage over time

Expected behaviour

Actual behaviour

5 minutes after starting iri/nelson my CPU usage is typically about 40%
As hours goes by i see a gradual increase of CPU usage to the point where it reaches 90-100%.
This would typically occur after 24 hours.
At this point i also notice that the number of active connections are very low (0 or 1 connections)
Now, if i close and restart nelson (without closing iri) things goes back to normal (40% CPU and normal connection count)

Note! Im also running the Carriota Field service on this server.

Steps to reproduce

Basic Info

Operating System:
Unbuntu
Node (npm) Version:
5.6.0
IRI Version:
1.4.2.1
Nelson version:
0.4.0

Nelson Info

Epoch:
Cycle:
Connected peers:

Unit tests fail sporadically

Sometimes heart-test.js fails with:
Using Ubuntu 16.04
node -v: 9.1.0

 FAIL  src/node/__tests__/heart-test.js (23.599s)
  ● Heart › updates personality correctly

    Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.
      
      at node_modules/jest-jasmine2/build/queue_runner.js:64:21
      at Timeout.callback [as _onTimeout] (node_modules/jsdom/lib/jsdom/browser/Window.js:523:19)
      at ontimeout (timers.js:478:11)
      at tryOnTimeout (timers.js:302:5)
      at Timer.listOnTimeout (timers.js:262:5)

FYI @romansemko

Closing Nelson 0.3.1 will also remove all static neighbors

Expected behaviour

Closing Nelson should not remove static neighbors.

Actual behaviour

Closing Nelson does remove static neighbors.

Steps to reproduce

Start IRI with at least one static neighbor
Check neighbor count via api -> should say 1 (or X).
Start Nelson with --getNeighbors
Check neighbor count again should say 1+Y (or X+Y)
Close Nelson
Check neighbor count again and it says 0

Basic Info

Operating System:
Node (npm) Version: 8.9.3
IRI Version: 1.4.1.4
Nelson version: 0.3.1

Error: WebSocket

Idk what this means but I'm seeing it pop up a lot in my nelson.cli terminal gui(IPv6 address edited out):

│19:11:35.811 16600::NODE Error binding/adding ::ffff:..1.** 16600 │
│Error: WebSocket is not open: readyState 3 (CLOSED)

The address always appears to be an IPv4 address mapped to IPv6 format.

Nelson's otherwise working just fine.

Operating System: Ubuntu 16.04
Node (npm) Version: 8.9.4
IRI Version: 1.4.2.2
Nelson version: 0.4

"You have triggered an unhandledRejection, you may have forgotten to catch a Promise rejection" Error

Expected behaviour

Unsure

Actual behaviour

Sometimes this causes Nelson to stop finding new peers, other time it seems to not cause any direct problem.

Steps to reproduce

Currently running a network of 12 Nodes, This error is appearing on almost all of my nodes. Followed Guide for install on the github page. Im also running nelson under PM2 with my own config. (Can provide config if needed)

Basic Info

Operating System: Linux Ubuntu 16.04 LTS
Node (npm) Version: 9+
IRI Version: v1.4.2.1
Nelson version: 0.4.0

Nelson Info

Epoch: Different on each node
Cycle: Different on each node
Connected peers: Different on each node

Error message -

You have triggered an unhandledRejection, you may have forgotten to catch a Promise rejection:
at WebSocket.initAsClient (/usr/lib/node modules/nelson.cli/node modules/ws/lib/websocket.js:529:11)
at new WebSocket (/usr/lib/node modules/nelson.cli/node_modules/ws/lib/websocket.js:71:20)
at Node.connectPeer (/usr/lib/node modules/nelson.cli/dist/node/node.js:916:33)
at /usr/lib/node modules/nelson.cli/dist/node/node.js:954:32
at Array.map ()
at Node.reconnectPeers /usr/lib/node modules/nelson.cli/dist/node/node.js:953:32)
at /usr/lib/node modules/nelson.cli/dist/node/node.js: 1051:29
at new Promise ()
at Node._onTick(/usr/lib/node modules/nelson.cli/dist/node/node.js 1050:24)
at Heart._tick (/usr/lib/node_modules/nelson.cli/dist/node/heart.js: 124:23)

Aerowave#5383 is reporting the same Issue on discord:

Aerowave - Today at 6:57 AM
Hi, I'm having an issue with Nelson this morning, similar to @typpi ... after connecting to IRI Nelson terminates with an unhandled promise rejection. Nothing's changed on my config recently, only rebooted the server this morning, now it won't find any neighbours again? Thanks in advance

Contact:

Contact me on Discord at Typpi#3906 or email at [email protected]

Thanks!

Running nelson with docker-compose

Hello,

i'm trying to run nelson with docker-compose, but nelson fails to connecting to iri.

Expected behaviour

Nelson connects to iri.

Actual behaviour

Nelson does not connect to iri. Logs:

$ docker-compose up                                                                                                                                                                                                                               [14:53:59]
Recreating iotanet_iri_1 ... done
Recreating iotanet_nelson_1 ... done
Attaching to iotanet_iri_1, iotanet_nelson_1
iri_1     | 02/14 13:54:07.415 [main] INFO  com.iota.iri.IRI - Remote access enabled. Binding API socket to listen any interface.
iri_1     | 02/14 13:54:07.430 [main] INFO  com.iota.iri.IRI - Welcome to IRI 1.4.2.1
nelson_1  | 13:54:09.520	16600::IRI   IRI not ready on iri:14265, retrying...
nelson_1  | 13:54:14.535	16600::IRI   IRI not ready on iri:14265, retrying...
nelson_1  | 13:54:19.545	16600::IRI   IRI not ready on iri:14265, retrying...
iri_1     | 02/14 13:54:23.746 [main] INFO  c.i.i.s.r.RocksDBPersistenceProvider - Initializing Database Backend... 
iri_1     | 02/14 13:54:24.283 [main] INFO  c.i.i.s.r.RocksDBPersistenceProvider - RocksDB persistence provider initialized.
iri_1     | 02/14 13:54:24.334 [main] INFO  com.iota.iri.network.UDPReceiver - UDP replicator is accepting connections on udp port 14777
iri_1     | 02/14 13:54:24.344 [UDP receiving thread] INFO  com.iota.iri.network.UDPReceiver - Spawning Receiver Thread
iri_1     | 02/14 13:54:24.345 [UDP receiving thread] INFO  com.iota.iri.network.UDPReceiver - Receiver thread processed/dropped ratio: 0/0
iri_1     | 02/14 13:54:24.347 [main] INFO  c.i.i.network.replicator.Replicator - Started ReplicatorSourcePool
iri_1     | 02/14 13:54:24.369 [Thread-2] INFO  c.i.i.n.r.ReplicatorSourcePool - TCP replicator is accepting connections on tcp port 15777
iri_1     | 02/14 13:54:24.385 [pool-2-thread-1] INFO  com.iota.iri.network.Node - Spawning Broadcaster Thread
nelson_1  | 13:54:24.554	16600::IRI   IRI not ready on iri:14265, retrying...
iri_1     | 02/14 13:54:25.022 [pool-2-thread-5] INFO  com.iota.iri.network.Node - Spawning Reply To Request Thread
iri_1     | 02/14 13:54:25.032 [pool-2-thread-2] INFO  com.iota.iri.network.Node - Spawning Tips Requester Thread
iri_1     | 02/14 13:54:25.032 [pool-2-thread-4] INFO  com.iota.iri.network.Node - Spawning Process Received Data Thread
iri_1     | 02/14 13:54:25.032 [pool-2-thread-3] INFO  com.iota.iri.network.Node - Spawning Neighbor DNS Refresher Thread
iri_1     | 02/14 13:54:25.035 [pool-2-thread-3] INFO  com.iota.iri.network.Node - Checking Neighbors' Ip...
iri_1     | 02/14 13:54:25.036 [pool-2-thread-2] INFO  com.iota.iri.network.Node - toProcess = 0 , toBroadcast = 0 , toRequest = 0 , toReply = 0 / totalTransactions = 0
nelson_1  | 13:54:29.566	16600::IRI   IRI not ready on iri:14265, retrying...
nelson_1  | 13:54:34.574	16600::IRI   IRI not ready on iri:14265, retrying...
iri_1     | 02/14 13:54:35.037 [pool-2-thread-2] INFO  com.iota.iri.network.Node - toProcess = 0 , toBroadcast = 0 , toRequest = 0 , toReply = 0 / totalTransactions = 0
nelson_1  | 13:54:39.581	16600::IRI   IRI not ready on iri:14265, retrying...
nelson_1  | 13:54:44.585	16600::IRI   IRI not ready on iri:14265, retrying...
iri_1     | 02/14 13:54:44.642 [main] INFO  com.iota.iri.IRI - IOTA Node initialised correctly.
iri_1     | 02/14 13:54:45.041 [pool-2-thread-2] INFO  com.iota.iri.network.Node - toProcess = 0 , toBroadcast = 0 , toRequest = 0 , toReply = 0 / totalTransactions = 0
nelson_1  | 13:54:49.675	16600::IRI   IRI not ready on iri:14265, retrying...
nelson_1  | 13:54:54.685	16600::IRI   IRI not ready on iri:14265, retrying...
iri_1     | 02/14 13:54:55.043 [pool-2-thread-2] INFO  com.iota.iri.network.Node - toProcess = 0 , toBroadcast = 0 , toRequest = 0 , toReply = 0 / totalTransactions = 0
[...]

Steps to reproduce

Use my docker compose file:

version: '3'

services:
  iri:
    image: iotaledger/iri
    ports:
      - "14265:14265"
      - "14777:14777"
      - "15777:15777"
  nelson:
    image: romansemko/nelson.cli
    command: -r iri -i 14265 -u 14777 -t 15777 --neighbors "mainnet.deviota.com/16600 mainnet2.deviota.com/16600 mainnet3.deviota.com/16600 iotairi.tt-tec.net/16600"
    ports:
      - "16600:16600"

Basic Info

Operating System: Ubuntu 16.04
Node (npm) Version: v8.9.4 (5.6.0)
IRI Version: 1.4.2.1
Nelson version: 0.4.0

Nelson Info

Epoch: N.A.
Cycle: N.A.
Connected peers: N.A.

On some machines GUI is not displayed properly in the terminal.

The problem might be that the given terminal does not allow special chars. Why the first column is cut, however, I cannot explain.

TypeError [ERR_INVALID_URL]: Invalid URL: nelson1.carriota.com/14600

Ubuntu 16.04
node -v: 9.1.0

How to reproduce:
yarn make
node ./dist/nelson.js --neighbors nelson1.carriota.com/14600 nelson2.carriota.com/14600

Error throws:

TypeError [ERR_INVALID_URL]: Invalid URL: nelson1.carriota.com/14600
    at onParseError (internal/url.js:219:17)
    at parse (internal/url.js:228:3)
    at new URL (internal/url.js:311:5)
    at /home/wit/Dev/nelson.cli/dist/nelson.js:23:16
    at Array.map (<anonymous>)
    at parseNeighbors (/home/wit/Dev/nelson.cli/dist/nelson.js:22:27)
    at Command.<anonymous> (/home/wit/Dev/nelson.cli/node_modules/commander/index.js:394:35)
    at emitOne (events.js:125:13)
    at Command.emit (events.js:221:7)
    at Command.parseOptions (/home/wit/Dev/nelson.cli/node_modules/commander/index.js:719:14)

Node NOT SYNCED error

Expected behaviour

Hello, I have run my own IOTA full node (iri + nelson) on a VPS.

Actual behaviour

When I try to connect to my server via a desktop client, I get NOT SYNCED error when clicking on LOGIN button. Other official nodes work well.

Steps to reproduce

On the server:
docker run -d --net host -p 14265:14265 --name iri iotaledger/iri
docker run -d --net host -p 18600:18600 --name nelson romansemko/nelson.cli -r localhost -i 14265 -u 14777 -t 15777 --neighbors "mainnet.deviota.com/16600 mainnet2.deviota.com/16600 mainnet3.deviota.com/16600 iotairi.tt-tec.net/16600"

On your computer:

Launch IOTA Desktop Wallet
Tools --> Edit node configuration
Set custom host to http://iota.full.node.com:14265
Save
Enter a seed and click LOGIN

My quesions are,
Do I have to wait for my full node to be fully synced ? Is the sync process broken ?

Thanks for reading me,
lapwat

Basic Info

Operating System: Ubuntu Zesty (17.04 latest)
Node (npm) Version: Docker image romansemko/nelson.cli:latest
IRI Version: 1.4.1.6 Docker image iotaledger/iri:latest
Nelson version: 0.3.16 Docker image romansemko/nelson.cli:latest

Nelson Info

Epoch: 1200
Cycle: 60
Connected peers: 3

Add versioning to the api

Expected behaviour

Since the api might change in the feature, we do not want to break stuff, thats why we should consider adding a versioning in the url

sth like :18600/nelson/v1/
or :18600/nelson/v1/peers/

Actual behaviour

no versioning in the api currently

Limit the number of nodes

Expected behaviour

Actual behaviour

Steps to reproduce

Basic Info

Operating System:
Node (npm) Version:
IRI Version:
Nelson version:

Nelson Info

Epoch:
Cycle:
Connected peers:

IRI node not ready

Basic Info

Operating System: Debian
Node (npm) Version: 5.6.0
IRI Version: 1.4.2.2
Nelson version: 0.4.0

Hi,

so I installed Nelson and ran it on my node that is running 24/7. But it doesn't seem to be able to connect to the Node. I threw out the mainnetdb and resynced, just in case. But so far no cigar.

As the error message seems to put the fault of it on the Node side, is there anything I have to put in the .ini file of the iri-node to make it able to connect with the Nelson process ?

Cheers,

Nelson drops all peers: Unhandled Rejection at: Promise Promise { <rejected> undefined } reason: undefined

Expected behaviour

Nelson connected with peers continuously

Actual behaviour

Nelson drops all my peers after hours, doesn't reconnect with any of them

Steps to reproduce

Start nelson with screen -S nelson nelson --config ~/config.ini

Basic Info

Operating System: Ubuntu Server 16.04
Node (npm) Version:

$ node -v
v8.11.1
$ npm -v
5.6.0
atverm@iota:~$

IRI Version: 1.4.2.2
Nelson version: 0.4.0

Nelson Info

Epoch: Unknown
Cycle: Unknown
Connected peers: 0

Nelson works fine, until after a few hours (around 6? hours) it drops all peers, displaying: Unhandled Rejection at: Promise Promise { <rejected> undefined } reason: undefined in the left top corner of the gui. All the gui shows while in this state is that it's dropping connections, and Nelson doesn't connect to any peers until restarted.

Nelson config:

[nelson]
name = *****
cycleInterval = 60
epochInterval = 300
apiPort = 18600
apiHostname = 127.0.0.1
port = 16600
IRIHostname = localhost
IRIProtocol = any
IRIPort = 14265
TCPPort = 15600
UDPPort = 14600
dataPath = data/neighbors.db
; maximal incoming connections. Please do not set below this limit:
incomingMax = 10
; maximal outgoing connections. Only set below this limit, if you have trusted, manual neighbors:
outgoingMax = 10
isMaster = false
silent = false
gui = true
getNeighbors = https://raw.githubusercontent.com/SemkoDev/nelson.cli/master/ENTRYNODES
; add as many initial Nelson neighbors, as you like
neighbors[] = mainnet.deviota.com/16600
neighbors[] = mainnet2.deviota.com/16600
neighbors[] = mainnet3.deviota.com/16600
neighbors[] = iotairi.tt-tec.net/16600

; Protect API with basic auth
[nelson.apiAuth]
username=******
password=*******

Suggestion: Add IRI status

Please write latest milestone and latest solid milestone statistics from IRI on the GUI somewhere. Any other info from getNodeInfo would also be good. That way Nelson GUI can act as a status page for IRI as well.

Nelson removed "manual" neighbours if both are running Nelson.

Expected behaviour

Nelson keeps the neighbours untouched.

Actual behaviour

Nelson deletes them.

Steps to reproduce

Run two nodes that manually add each other. Run Nelson on both nodes. After a while, the connection gets deleted.

Peer list test fails on make

Expected behaviour

No test failures when running yarn make on master.

Actual behaviour

command line:

yarn make
yarn run v1.3.2
$ npm run test && npm run build && npm run make:binaries

> [email protected] test /home/.../prog/nelson.cli
> jest -b

 PASS  src/api/__tests__/api-test.js (13.519s)
 FAIL  src/node/__tests__/peer-list-test.js (26.382s)
  ● PeerListTest › should return correct peer trusts

    expect(received).toBeGreaterThan(expected)
    
    Expected value to be greater than:
      1
    Received:
      0.5447916099999999
      
      at src/node/__tests__/peer-list-test.js:265:70
          at <anonymous>

Test Suites: 1 failed, 1 passed, 2 of 10 total
Tests:       1 failed, 21 passed, 22 total
Snapshots:   0 total
Time:        29.779s
Ran all test suites.
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] test: `jest -b`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] test script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/.../.npm/_logs/2018-02-18T09_59_22_012Z-debug.log
error Command failed with exit code 1.

018-02-18T09_59_22_012Z-debug.log:

0 info it worked if it ends with ok
1 verbose cli [ '/usr/bin/node', '/usr/bin/npm', 'run', 'test' ]
2 info using [email protected]
3 info using [email protected]
4 verbose run-script [ 'pretest', 'test', 'posttest' ]
5 info lifecycle [email protected]~pretest: [email protected]
6 info lifecycle [email protected]~test: [email protected]
7 verbose lifecycle [email protected]~test: unsafe-perm in lifecycle true
8 verbose lifecycle [email protected]~test: PATH: /usr/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/home/.../prog/nelson.cli/node_modules/.bin:/home/.../prog/nelson.cli/node_modules/.bin:/home/.../.config/yarn/link/node_modules/.bin:/home/.../prog/nelson.cli/node_modules/.bin:/home/.../.config/yarn/link/node_modules/.bin:/home/.../.yarn/bin:/usr/lib/node_modules/npm/bin/node-gyp-bin:/usr/bin/node_modules/npm/bin/node-gyp-bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/opt/maven/bin
9 verbose lifecycle [email protected]~test: CWD: /home/.../prog/nelson.cli
10 silly lifecycle [email protected]~test: Args: [ '-c', 'jest -b' ]
11 silly lifecycle [email protected]~test: Returned: code: 1  signal: null
12 info lifecycle [email protected]~test: Failed to exec test script
13 verbose stack Error: [email protected] test: `jest -b`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (/usr/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:285:16)
13 verbose stack     at EventEmitter.emit (events.js:160:13)
13 verbose stack     at ChildProcess.<anonymous> (/usr/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack     at ChildProcess.emit (events.js:160:13)
13 verbose stack     at maybeClose (internal/child_process.js:943:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:220:5)
14 verbose pkgid [email protected]
15 verbose cwd /home/.../prog/nelson.cli
16 verbose Linux 4.9.0-5-amd64
17 verbose argv "/usr/bin/node" "/usr/bin/npm" "run" "test"
18 verbose node v9.5.0
19 verbose npm  v5.6.0
20 error code ELIFECYCLE
21 error errno 1
22 error [email protected] test: `jest -b`
22 error Exit status 1
23 error Failed at the [email protected] test script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

(replaced my user name with three dots)

Steps to reproduce

Follow steps on https://github.com/SemkoDev/nelson.cli for building locally.

Basic Info

Operating System: Debian (Linux 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux)
Node (npm) Version: 5.6.0
IRI Version: 1.4.2.1
Nelson version: current master (1db62e4)

Nelson Info

Epoch:
Cycle:
Connected peers:

Can not start nelson

Expected behaviour

nelson should run

Actual behaviour

nelson craches with following output:

Unhandled Rejection at: Promise Promise {
  <rejected> TypeError: URL is not a constructor
  at /usr/local/lib/node_modules/nelson.cli/dist/node/iri.js:79:40
  at Array.map (native)
  at /usr/local/lib/node_modules/nelson.cli/dist/node/iri.js:78:55
  at makeRequest.prepareResult 
  (/usr/local/lib/node_modules/nelson.cli/node_modules/iota.lib.js/lib/utils/makeRequest.js:313:12)
  at request.onreadystatechange 
  (/usr/local/lib/node_modules/nelson.cli/node_modules/iota.lib.js/lib/utils/makeRequest.js:71:25)
  at dispatchEvent 
 (/usr/local/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:591:25)
at setState (/usr/local/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:610:14)
at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:447:13)
at emitNone (events.js:91:20)
at IncomingMessage.emit (events.js:185:7) } reason: TypeError: URL is not a constructor
at /usr/local/lib/node_modules/nelson.cli/dist/node/iri.js:79:40
at Array.map (native)
at /usr/local/lib/node_modules/nelson.cli/dist/node/iri.js:78:55
at makeRequest.prepareResult (/usr/local/lib/node_modules/nelson.cli/node_modules/iota.lib.js/lib/utils/makeRequest.js:313:12)
at request.onreadystatechange (/usr/local/lib/node_modules/nelson.cli/node_modules/iota.lib.js/lib/utils/makeRequest.js:71:25)
at dispatchEvent (/usr/local/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:591:25)
at setState (/usr/local/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:610:14)
at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:447:13)
at emitNone (events.js:91:20)
at IncomingMessage.emit (events.js:185:7)

Steps to reproduce

start nelson with following command

nelson --gui --isMaster --epochInterval 180 --neighbors "mainnet.deviota.com/16600 mainnet2.deviota.com/16600 iotairi.tt-tec.net/16600 voss-hosting.de/16600 iotanode.party/16600 nelson.vanityfive.de/16600 45.77.187.45/16600 tanglenode.de/16600 nelson.iota.fm/16000"

Basic Info

Operating System:
Ubuntu-1710-artful-64-minimal
Node (npm) Version:
3.5.2
IRI Version:
1.4.1.7
Nelson version:
0.3.21

Nelson removing manual neighbours defined via FQDN

Expected behaviour

Nelson does not touch manually added iri neighbours

Actual behaviour

If nelson discovers a neighbour that is already added to iri via fqdn, it may remove it

Steps to reproduce

Add neighbour to iri via fqdn(not IP)
Said neighbour also runs Nelson
Nelson discovers and connects to neighbour via IP
Nelson removes neighbour

Basic Info

Operating System: Centos 7
Node (npm) Version: 3.10.10
IRI Version: 1.4.1.4
Nelson version: 2.4.4

Nelson Info

Epoch:
Cycle:
Connected peers:

Nelson has no max cap on number of nodes added as neighbours

Expected behaviour

Capping the number of active neighbours. Command line flag?

Actual behaviour

There appears to be no cap on how many neighbours Nelson adds over time, exceeding the recommended max of 7.

Steps to reproduce

Run Nelson for several hours.

Basic Info

Linux server 14.04
NPM 5.5.1
IRI 1.4.1.2
Nelson 0.1.11

Nelson Info

N/A

Error starting nelson

OS: Ubuntu Xenial
Kernel: 4.4.27-x86_64-jb1

npm install -g nelson.cli
==> OK

nelson --gui --getNeighbors
==> see below

/usr/local/lib/node_modules/nelson.cli/node_modules/external-ip/lib/extIP.js:5
module.exports = (externalConfig = {}) => {
^
SyntaxError: Unexpected token =
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:374:25)
at Object.Module._extensions..js (module.js:417:10)
at Module.load (module.js:344:32)
at Function.Module._load (module.js:301:12)
at Module.require (module.js:354:17)
at require (internal/module.js:12:17)
at Object. (/usr/local/lib/node_modules/nelson.cli/node_modules/external-ip/index.js:2:18)
at Module._compile (module.js:410:26)
at Object.Module._extensions..js (module.js:417:10)

Unexpected death of Nelson process - TCP error

Expected behaviour

Uninterrupted operation.

Actual behaviour

Nelson died with:
Error: read ECONNRESET
at exports._errnoException (util.js:1020:11)
at TCP.onread (net.js:568:26)

Steps to reproduce

Unknown. Nelson had been running for 10 hours and 15 minutes (scrollback in screen session).

Basic Info

Operating System: Ubuntu 17.10
Node (npm) Version: 3.5.2
IRI Version: 1.4.1.6
Nelson version: 0.3.12

Nelson Info

Epoch: 112 (at 1% of current epoch)
Cycle: 559 (at 1% of currency cycle)
Connected peers: 9

Add "running as master" information in gui

Would be awesome since it was not clear for me until i checked the listening ports on my host.

Add NELSON_CONFIG environment var checking

The env variable should hold a path to the Nelson's config file.

Feature request: optional forced iri update

Hello,

First: I've had a long and productive talk with h3n. He helped to see things more clearly. Thx.

My problem with the network: There are now several versions in the wild. The most recent is 1.4.1.4. But as hugh network it should stay as monolithic as possible. So older versions should deprecate over time and defunced.

I propose that every nelson installation should be able to learn about new versions automatically. If there is a confirmed new version found then the local node is forced to update (optional but default: on) the IRI at a random point within lets say 30 days. After that plus a grace time the local nelson can discard older nodes because there virtually none.
If you need to install an old version for what ever reason then just switch off this option.

Positive:

One network, one version
~30 days to revoke a version
all nodes have 99.995% uptime within the update time (asuming 30 seconds restart time within these 30 days)
network downtime closest to 0%
new versions only need to know how to talk to version minus 1
option is optional :)
nelsons learn about the version distribution in the network

Negative:

single outdated nodes are bound to their one small world (micro netsplit)

... and no, hardware nodes a unlikely full nodes. So there is no point here.

This can work.
Please discuss it before you close it.

Michael

API not working properly

Expected behaviour

get a response from the root endpoint "/"

Actual behaviour

getting an empty or no response

Steps to reproduce

when making the api call from the browser direct or via jquery i.e._
$.getJSON("http://localhost:18600", function (data) { console.log(data); });

only getting an emtpy response.

Basic Info

Operating System: Windows
Node (npm) Version: 8.9.3 (5.5.1)
IRI Version: 1.4.1.4
Nelson version: 0.2.2

Nelson Info

Epoch: 3
Cycle: 35
Connected peers: 5

add check if port 16600 is open when starting nelson

all the while i thought i was running nelson correctly. now and then i saw for a short time a new dynamic node....so i thought everything was fine. however i became a bit suspicious after i checked my nelson logs and i always saw these new connections getting dropped almost instantaneously.

after a bit of research i finally realized i forgot to open port 16600. my suggestion would be therefore to add a check if port 16600 is open when one starts nelson and throw an error if port is firewalled.

Nelson crashes after a few hours/days

I don't run nelson as a service. I run it using the command:

nohup sudo nelson --config /Users/iota/nelson/config.ini &

Just happened for the 3rd time. I go to check my node and found out that nelson is not running. This last time it was running for almost 24 hours before crashing. More details in the log below.

Expected behaviour

Nelson running continuously

Actual behaviour

After a while, can be hours or a few days, Nelson crashes.

Steps to reproduce

Not sure. It crashes randomly

Basic Info

Operating System: Macos High Sierra (10.13.2)
Node (npm) Version: v8.4.0
IRI Version: 1.4.1.6
Nelson version: 0.3.16

Nelson Info

Epoch: don't know
Cycle: don't know
Connected peers: my configuration is 6 in, 5 out

8:30:23 AM.190 16600::NODE new cycle
8:30:23 AM.195 16600::IRI Neighbors removed (if there were any): udp://31.48.190.3:14600
8:30:23 AM.195 16600::NODE connection closed 31.48.190.3:16600 (remotely dropped)
8:30:23 AM.195 16600::IRI Neighbors removed (if there were any): udp://139.226.182.140:14600
8:30:23 AM.195 16600::NODE connection closed 139.226.182.140:16600 (remotely dropped)
8:30:23 AM.196 16600::IRI Neighbors removed (if there were any): udp://31.48.190.3:14600
8:30:23 AM.196 16600::IRI Neighbors removed (if there were any): udp://139.226.182.140:14600
/usr/local/lib/node_modules/nelson.cli/node_modules/ws/lib/WebSocket.js:638
this._req.abort();
^

TypeError: Cannot read property 'abort' of null
at ClientRequest._req.setTimeout (/usr/local/lib/node_modules/nelson.cli/node_modules/ws/lib/WebSocket.js:638:16)
at Object.onceWrapper (events.js:314:30)
at emitNone (events.js:105:13)
at ClientRequest.emit (events.js:207:7)
at Socket.emitTimeout (_http_client.js:722:34)
at Object.onceWrapper (events.js:314:30)
at emitNone (events.js:105:13)
at Socket.emit (events.js:207:7)
at Socket._onTimeout (net.js:398:8)
at ontimeout (timers.js:469:11)

ReferenceError: reject is not defined

This could be a bug. Never saw this before on my ~100 identical instances.

Steps to reproduce

No idea.

Basic Info

Operating System: Alpine 3.7
Node (npm) Version: 9.11.1 / 5.6.0
IRI Version: 1.4.2.2
Nelson version: 0.4.0

Nelson Info

Epoch: don't know
Cycle: don't know
Connected peers: max 9

23:26:57.114 16600::IRI Removed orphans: iotanode.party,mainnet2.deviota.com,
04/16 23:26:59.135 [pool-2-thread-2] INFO com.iota.iri.network.Node - toProcess = 0 , toBroadcast = 0 , toRequest = 231 , toReply = 0 / totalTransactions = 12495911,
04/16 23:26:59.347 [XNIO-1 task-173] INFO com.iota.iri.service.API - Adding neighbor: udp://mainnet2.deviota.com:14600,
23:26:59.348 16600::IRI Neighbors added: udp://mainnet2.deviota.com:14600,
04/16 23:26:59.818 [XNIO-1 task-172] INFO com.iota.iri.service.API - Adding neighbor: udp://iotanode.party:14600,
23:26:59.821 16600::IRI Neighbors added: udp://iotanode.party:14600,
23:26:59.854 16600::NODE terminating...,
04/16 23:26:59.856 [XNIO-1 task-177] INFO com.iota.iri.service.API - Removing neighbor: udp://62.226.68.29:14600,
04/16 23:26:59.856 [XNIO-1 task-177] INFO com.iota.iri.service.API - Removing neighbor: udp://eu1.tangleno.de:14600,
04/16 23:26:59.856 [XNIO-1 task-177] INFO com.iota.iri.service.API - Removing neighbor: udp://136.243.73.66:14600,
23:26:59.857 16600::IRI Neighbors removed (if there were any): udp://62.226.68.29:14600, udp://eu1.tangleno.de:14600, udp://136.243.73.66:14600,
Unhandled Rejection at: Promise Promise {,
ReferenceError: reject is not defined,
at /usr/lib/node_modules/nelson.cli/dist/node/iri.js:252:33,
at makeRequest.prepareResult (/usr/lib/node_modules/nelson.cli/node_modules/iota.lib.js/lib/utils/makeRequest.js:315:12),
at exports.XMLHttpRequest.request.onreadystatechange (/usr/lib/node_modules/nelson.cli/node_modules/iota.lib.js/lib/utils/makeRequest.js:71:25),
at exports.XMLHttpRequest.dispatchEvent (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:591:25),
at setState (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:610:14),
at exports.XMLHttpRequest.handleError (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:532:5),
at ClientRequest.errorHandler (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:459:14),
at ClientRequest.emit (events.js:180:13),
at Socket.socketErrorListener (_http_client.js:395:9),
at Socket.emit (events.js:180:13) } reason: ReferenceError: reject is not defined,
at /usr/lib/node_modules/nelson.cli/dist/node/iri.js:252:33,
at makeRequest.prepareResult (/usr/lib/node_modules/nelson.cli/node_modules/iota.lib.js/lib/utils/makeRequest.js:315:12),
at exports.XMLHttpRequest.request.onreadystatechange (/usr/lib/node_modules/nelson.cli/node_modules/iota.lib.js/lib/utils/makeRequest.js:71:25),
at exports.XMLHttpRequest.dispatchEvent (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:591:25),
at setState (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:610:14),
at exports.XMLHttpRequest.handleError (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:532:5),
at ClientRequest.errorHandler (/usr/lib/node_modules/nelson.cli/node_modules/xmlhttprequest/lib/XMLHttpRequest.js:459:14),
at ClientRequest.emit (events.js:180:13),
at Socket.socketErrorListener (_http_client.js:395:9),
at Socket.emit (events.js:180:13)

Add paging mechanism to /peer api endpoint

Expected behaviour

when calling the Endpoint there should be a metadatalist which contains the following information:
totalPeers:
numberOfPeers:
offset:
data:

the totalPeers are the total number of peers in the peer.list
numberOfPeers are the number of peers contained in the data object
offset: how many peers are skipped.
data: the actual peer objects

This would need a sorting at some point, i suggest data._id from the peer as a sorting indicator.

Actual behaviour

you get all the peers at once

Steps to reproduce

make a call to /peers

test peer-test.js fails

Expected behaviour

The test should not fail.

Actual behaviour

FAIL src/node/tests/peer-test.js
● Peer › should return correct tcp, http and hostname strings

expect(received).toEqual(expected)

Expected value to equal:
  "tangle.com/666/777/888"
Received:
  "tangle.com/666/777/888/0/udp"
  
  at Object.<anonymous> (src/node/__tests__/peer-test.js:21:36)
  at process._tickCallback (internal/process/next_tick.js:109:7)

Steps to reproduce

git clone https://github.com/SemkoDev/nelson.cli.git
git checkout 0.3.12-beta
yarn install --pure-lockfile
yarn make

Basic Info

Operating System: Ubuntu 16.04 LTS
Node (npm) Version: node v6.12.2, npm 3.10.10
IRI Version: 1.4.1.4
Nelson version: 0.3.12-beta