Week 28:

Final Week!

The main aim for this week was to get this rewrite function working, once and for all.

The rewrite function needed to comprise of a sender, a receiver, a hash broadcast and a most common hash detector.

I decided it was best first delve into the emitter() function, as this was responsible for letting other nodes know the quality of it's data.

After some tests I realised that by importing time, the nodes could all broadcast their hash at the same time. This would make it easier for the node detector as all the information should arrive within milliseconds of each other.

Problem:

The emitter creates a hash the same as before using a For loop nested in two other For loops. There was no way of finding out how long it takes the For loop to finish as more data was always being added but I needed a way to broadcast every multiple of 5 seconds, like all the other nodes.

Solution:

Using the modulus maths operator returns a remainder. For example, 5 % 5 = 0, 4 % 5 = 4. Usage this operator, I was able to find how far away from a multiple of five was.

If the For loop finished at an unknown time, taking a reading of time at that point and feeding it into a modulus function it will return the time needed to wait before publishing the data. For example, time.sleep(5 - (seconds % 5)). The modulus function is subtracted from 5 because modulus normally says how far away, lower or higher. In order for it to say how long to wait until the next multiple, subtracting from five works well.

A revamp of the detector was needed as well. I realised that if a node is restarted in the middle of an order due to power loss, etc, using the rosnode.rosnode_ping_all() function, it was able to update an array if nodes were online or not. This was another preemptive move for being one step closer to the eluding node rewrite function.

When a node is being rewritten, it's last hash does not want to be considered again for being compromised if it's already in the process of being rewritten. If that happens, like it has before, the node only gets half rewritten, therefore never being able to fully rewrite.

Problem:

Once a node was detected as being hacked there was always a possibility that the node's hash was just received late.

Solution:

To combat this, that node's name was saved. When the loop came round again to the next multiple of five, if that node was still being the one accused of false data, it meant that node is highly likely to be compromised.

The rewrite function:

After many different tests and design iterations I finally settled on a way to send the most data in the quickest way.

Sending data over ROS line by line is slow and data can be missed, however, sending one long string of all the concatenated array data is very fast.

This long string is created and separated in by either ';' or '?'.

'?' separates each block in the blockchain and ';' separates each item of data in that block.

Parsing the data on the other side first splits the string into an array with each index beginning and end where the '?' was.

Finding the length of this array give the amount of loops the For loop had to do in order to parse all the data successfully.

The second split separated each index of the first split into a new array that gets rewritten at each loop. All the data can then be collected into arrays separated by [order][carrier][block] again, like before.

While still in the For loop, the blockchain be rebuilt as soon as the variables are assigned, which is quicker than before. The picture above shows if the station name = 'Start Production', it meant it was a genesis block. If the station name was a number, the blockchain was appended with new data.

In testing on the laptop, the program works flawlessly without any errors. The nodes only get rewritten once they are compromised.

In testing on the Pi's, the program is a bit too CPU intensive for rapid concatenation in that kind of time frame.

In future, a more powerful single board computer might be better equipped at handling the CPU surges.