After looking into code of IRI : all incoming transactions that aren't known yet (i.e. not already stored in the local tangle) are immediately stored in the local tangle and broadcasted to all neighbors.
There is a send_limit parameter that can be used to reduce the broadcast rate, but the default behavior is the broadcast every new transaction ASAP (...
"Nelson" is a wrapper which facilitates this for IRI. It is made by the carriota.com team. Some reference information so far on it (some people are already using Nelson). There are two blog posts on Medium about CarrIOTA Nelson:
CarrIOTA Nelson: Automatic peer discovery for IOTA
CarrIOTA Nelson in a nutshell
It looks like it can be installed via npm
The official IOTA cli-app has a health command that checks the health of the node. One of the checks is whether the node has between 4-9 neighbors. From Slack and everything published, that is as close to an official number as is currently available.
Visit "Discussion: Removing Peer Discovery" to read about it.
To quote briefly from the discussion:
[...] we've collected enough data to be able to determine that Peer Discovery is causing more problems than it does good.
Snapshotting: Peer Discovery basically makes it possible for previousu
transactions to be rebroadcast and ...
Considering how the Internet and its routing mechanisms work the hop count is not necessarily a stable metric and would have to be re-evaluated from time to time. Generally speaking though, the hop count is a decent metric to choose peers.
If you look at this paper for example the hop count is considered one of the better of eight metrics to rate "peer ...
No, different protocols will not work.
When receiving a packet from your neighbor, iri will validate if the source of the packet is in your neighbors list. As the port numbers differ, the packets will get rejected.
Broadcast of transactions just contains the transaction trytes, no other metadata (e.g. originator information). Therefore, IP addresses are only visible to immediate neighbors (and they can tell neither whether the transaction was injected at that node or just relayed)
The local transaction database stores some metadata about transactions that are not part ...
Current implementation of the IRI (1.5.3) :
is collecting statistics (here and here is the code).
don't implement anything regarding purge of lazy neighbors. (on the main net)
This task (i.e. purge of lazy neighbors) should be done either manually by the node operator, either through a third party script (like Nelson)
Using the IRI API, you can use getNeighbors to get the addresses and then getNodeInfo to obtain the latestSolidSubtangleMilestoneIndex and latestMilestoneIndex.
Only works if the neighbors have open APIs.
cURL examples, courtesy of https://iota.readme.io:
curl http://localhost:14265 \
-X POST \
-H 'Content-Type: application/json' \
For every invalid transaction from neighbor you will see one of those logs :
"Transaction processing runtime exception "
My interpretation : received data is corrupted in some way. Should be rare, unless your neighbor is voluntary spamming with garbage.
"Error accessing persistence store."
My interpretation : Problem maybe on your side. Your IRI is ...
check this out:
String name = instance.configuration.booling(Configuration.DefaultConfSettings.TESTNET) ? IRI.TESTNET_NAME : IRI.MAINNET_NAME;
return GetNodeInfoResponse.create(name, IRI.VERSION,
i.e. if you are looking at a list of nodes with their getNodeInfo data you might see: ...
Can it be that you are using the hostname, and the IP address of the neighbor changed since adding or restarting your node? To remove neighbors, your node compares protocol, resolved IP and port. In case the IP changed while your IRI was running, removing it with the same host name will fail (but removing it with the old IP should still work).
You can also ...