iota-tangle-io/iota-spamalot.go

Network spammer for IOTA written in Go

iota-spamalot.go's Issues

API: IsRunning() to check whether spammer is running

We need to a way to know whether the spammer is currently running. I suggest a IsRunning() bool or Running() bool method.

API: Metrics(), Transactions(), SpammingErrors() for getting the current spammer state

In order to let the coordinator know the state of the spammer, we need some data from it.

Metrics() which returns following things:

• current transaction per second
• failure rate over one minute
• load of the system (where as this can be left out for now)
• ...?

Transactions():

• all created transactions with time stamp and hash

SpammingErrors():

• returns error messages being "thrown" while spamming (with time stamps)

The idea is that the coordinator has enough data to conclude a health property of a slave.

TXs rate limiting by intercepting API calls to IRI (API proxy)

From @cwarner818 on January 26, 2018 16:0

Proxy commands to allow spamming only when node is idle, as well as pull metrics like # of connected clients, # of transactions sent, etc

Simplify package

I think we are currently doing too much in the package. It shouldn't run an endless loop, or spit out metric information to the user. Those are jobs for main packages. Spamalot should just handle generating spam transactions and collecting metrics and sending the transaction, but not all at once in an endless loop. We should have discrete steps for each of these and leave it to the main program to implement the loop.

Feature: Option for moving average for confirmation rate

Would be nice for knowing current network CTPS, as well as just generally faster reacting numbers.

Coordinator to slave API

From @luca-moser on January 26, 2018 18:50

As the the coordinator's job is to handle the entire configuration for its connected slaves (and their spammers), a set of commands has to be defined which a slave obeys to.

Commands indicating the desired action by the coordinator are handled as byte constants. A command has usually a payload with the argument data.

Note: In the entire setup, the coordinator is able to delegate commands directly to a spammer.

commands (byte constants):

single spammer:

• CREATE_SP; creates a new spammer
• READ_SP; re-polls data about a spammer's current state
• UPDATE_SP; stops the spammer and restarts it with a given configuration
• DELETE_SP; removes a given spammer by id
• RESTART_SP; restarts a spammer by given id

group:

• STOP_SPS: stops all spammers
• RESTART_SPS; restarts all spammers
• DELETE_SPS: deletes all spammers

A payload can be a spammer's configuration for example, consisting of depth, mwm...parameters.

Copied from original issue: iota-tangle-io/spamalot-project#3

Slave config parameters

From @luca-moser on January 26, 2018 18:49

Parameters which can be set for the spammers:

• depth
• mwm (minimal weight magnitude)
• node address (included port; i.e. http://iota-tangle.io:14265)
• tag
• message
• PoW mode (local or remote by node)
• cooldown time between txs

The configuration is sent down to the slave through the chosen transport.

Copied from original issue: iota-tangle-io/spamalot-project#2