[SOLVED] SER321 Assignment 5 Distributed Algorithms

Prerequisites

1. The assigned readings in module 5 on Canvas
2. Lecture videos from Canvas/ or class
3. Running and understanding the examples listed on the Canvas Module 5 page

Learning outcomes of this assignment are:

1. Understand basics of Distributed Algorithms
2. Evaluate distributed algorithms
3. Understand the basics of Consensus algorithms

Preliminary things

I strongly advise you to work on Git and GitHub, to version control and also to practice. If you work on GitHub make sure your repository is private.

Submit your assignment as always on GitHub in the appropriate directory and as zip on Canvas .

What you definitely need: 15 points

This part has a lot of points, you cannot receive all 15 points however in case you did not implement things or fulfilled less than 1/3 of the requirements at least partially.

1. You will create one project from scratch, your program needs to have a useful build.gradle file
2. A README.md
   1. Design your calls and user interaction in a way that they are easy.
   2. Include the command how we can run your program and in what order we need to call what in Gradle c) Explain your program
   3. Explain your protocol in detail (you can use any protocol type you want)
   4. Explain your encryption method
   5. Include a list of the requirements you think you fulfilled
   6. As always include a screencast that shows all your functionality – go through all requirements you fulfilled so we can already see it in your screencast if it works before we try it ourselves.

Distributed algorithm (85 points)

You start this activity from scratch. You can of course use any of the given example code as starter or inspiration.

The idea is to build a very simplified distributed algorithm network to encrypt a sentence. We also include a little simplified consensus algorithm. This is all very simplified just to give you a taste, you do not have to worry about security etc. but you should make sure your program is robust and well implemented.

Requirements

In here we will also grade with partial credit if you get part of it going and we can see these parts (based on when we run it, your Readme and your video). If we cannot run it we cannot award points.

You will need different parts that can be started:

1. A Leader: this one is also the one where the user can input data.
2. Nodes: all nodes have the same code, many nodes can be connected to the one leader.

The basic idea is that the user can input a sentence into the leader and that sentence will be split up as numberOfSymbols/nodesInNetwork. Then each node will get a part of that sentence to encrypt from the leader. What encryption you use does not matter as long as it is symbol by symbol. So no matter if it is split up between 1 or 50 nodes the encrypted message should be the same. The node will send the encrypted string back. The leader will then do a check to make sure no node is faulty. To do so the leader will send over an encrypted part and the corresponding decrypted part to each node (to a different one than the one that initially encrypt it) and the node needs to check if it is valid. It will return a yes/no if it thinks the encryption is valid. Only when all nodes return “yes” will the leader put the encrypted sentence back together and return it to the user.

See below for the requirements split up in more detail.

1. (3 points) Leader can be started through gradlerunLeader
2. (3 points) Nodes can be started through gradlerunNode−pPort = X−pLeaderPort = Y (port is its own port, leaderPort the leaders port)
3. (3 points) At least 3 Nodes should always be connected to the Leader
4. (2 points) Encryption should not work with less than 3 Nodes
5. (5 points) The Leader should be able to handle up to 8 Nodes
6. (3 points) Leader asks the user for a sentence
7. (4 points) The sentence received is split up based on the number of Nodes. If the sentence cannot be split up evenly then split it up as best as possible
8. (3 points) Leader sends a part of the sentence to each Node (each Node gets a different part)
9. (5 points) Leader should send it threaded so that the Nodes work in parallel on the encryption (imagine it is a really complicated encryption algorithm that takes a long time)
10. (6 points) Node receives the part of the sentence and runs some encryption algorithm (you choose which one)
11. (4 points) Node sends the encrypted part of the sentence back to Leader
12. (3 points) Leader receives the encrypted sentence parts
13. Leader starts a consensus for double checking the result
    1. (5 points) Leader sends each Node an encrypted and the corresponding decrypted part of the sentence (make sure it is not the same as the Node initially had – you can just shift)
    2. (5 points) This sending also happens in threads.
    3. (5 points) Node encrypts the string it gets again and matches against the encrypted one it received. If it matches it sends back an ok (or yes).
    4. (8 points) Nodes can be faulty: with a Gradle flag -pFault=1 allow that the node encrypts a received String wrong, thus it would return a “no” when it does the double check.
    5. (10 points) The Leader receives the answers, only when all vote “yes” will the encrypted message be put together again (make sure it is the correct order) and displayed for the customer.
    6. (13 points) If one node votes “no” (or more than one) you need to handle that since it means something if faulty. If the Leader catches this, then they should send a test String (from which it knows the encrypted answer) to the two Nodes which seem to have the discrepancy to check which one is faulty. It should receive an answer and should then eliminate the faulty Node from the Network. If both are faulty, remove both.
14. Overall good error handling, no crashing, users are informed of what is going on.

Should go without saying. We might deduct up to 10% if this is bad.