iota-tangle-io/spamalot-coo

A coordinator SPA which allows controlling a swarm of slaves which in turn control spammers.

spamalot-coo's Issues

Discussion: Transports between coo and slaves

We have currently two ideas in order to handle the transport of data between the coordinator and slaves.

Use MAM within the Tangle

The current state is that there's no MAM library for Go implemented by the IOTA foundation. MAM also gives us much higher latency. However, to leverage IOTA's technology is still an interesting approach to the problem.

As far as I comprehend, sending data with MAM involves doing PoW. Since slaves and the coo communicate bidirectional, both parties would have to do PoW. In order to mitigate this problem, we could setup IRI fullnodes only for the spammer infrastructure, which then do the PoW on behalf of the coo and slaves. The PoW on the slave's host introduces another problem, since another PoW is maybe already in the works when a spammer is creating a new TX.

Apparently there's a functioning JavaScript library, however it only works in conjunction with a fullnode doing the PoW.

I am open for ideas on how to exactly implement this.

HTTPS/WebSockets

Instead of using MAM on the Tangle, we could also simply connect the two parties with Websockets which are secured via TLS. The hurdle here is to have the TLS connection being verified and all, but once that's overcome it's very easy to implement.

Please share your thoughts.

Coordinator to slave API

From @cwarner818 on January 26, 2018 19:17

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

Copied from original issue: iota-tangle-io/iota-spamalot.go#1