Authentic Distributed Algorithm Homework Help Service

First, analyze, understand and run the given code (on localhost – so all nodes on localhost). You should have a good understanding of what is going on before you continue. Open up Wireshark to look at the traffic. Do the steps below and answer the questions in your Readme under a Task 1 section, number the questions according to the number in the following list (eg. Task 1, Point 1):

1. Explain the main structure of this code and the advantages and disadvantages of the setup of the distributed algorithm.

2. Run the code with different arrays to sort (different sizes, numbers, etc.) and include code to measure the time (you can just enter start and end times). In your Readme describe your experiments and your analyses of them. E.g. why is the result as it is? Does the distribution help? Why, why not? See this as setting up your own experiment and give me a good description and evaluation.

3. Experiment with the "tree" setup, what happens with more or fewer nodes when sorting the same array and different arrays? When does the distribution make things better? Does it ever make things faster? As in the previous step experiment and describe your experiment and your results in detail.

4. Explain the traffic that you see on Wireshark. How much traffic is generated with this setup and do you see a way to reduce it?

Right now the program runs only on localhost. Run the program not just on localhost, e.g. branch on your local computer, then two sorters on your main computer. So that traffic needs to leave your computer.

Open up Wireshark to look at the traffic. Answer the questions in your Readme under a

Task 2 section:

1. Do you expect changes in runtimes? Why, why not?

2. Do you see a difference in how long it takes to sort the arrays? Explain the differences (or why there are not differences)

Based on the questions above you hopefully have a good idea of where time is lost.

1. Where is the most time lost and could you make this more efficient?

2. Does it make sense to run the algorithm as a distributed algorithm? Why or why not?

Activity

You have a given Peer-2-peer network which is meant as a very simple chat tool. See the video and provided code. Video is linked in the Readme.

You should play with this example for a bit before getting started and decide on some things (these are questions for you, no answer in the Readme needed):

- What protocol do you plan on using? (JSON, Protobuf) - Do you want to stick to the simple BufferedReader/PrintWriter or exchange it with something you like better? - Understand where the client and where the server parts are in the code - Do you want to keep this code or make adjustments or rather start from scratch (not sure I advise that but it is up to you)

(8 points) As always you will need a Readme which has a little screencast where you show your project in action, explain everything we need to know about it. Also, explain your project in your readme and which requirements you were able to fulfill and explain your protocol.

(4 points) We want to be able to run the Client and server exactly as defined in the Readme and as is in Gradle. You should not need to change that. If you do for some reason, please ask first on Slack so we are aware and can discuss options.

You can assume that the nodes are initially started correctly, meaning first the leader then the nodes and that only one leader is started when you start up all your nodes.

Requirements

The requirements will add up to more than 48 points, so you can get some extra credit if you get everything done. The "big" points in here will also be graded with partial credit if you get part of it going and we can see that (based on when we run it, your Readme, and your video). If we cannot run it we cannot award points.

1. (3 points) Send the message "Hello what’s up?" which will not work in the chat. Fix that.

2. (8 points) Check that if a non-leader node (pawn) disconnects that it will be removed correctly. If one peer detects another nonleaded node not responding, the peer should inform the leader. The leader should then inform all other peers about the not responding node. If the leader detects it, it will just inform the others to remove this node.

3. (5 points) Make sure a peer is not entered twice into the list of peers.

4. (15 points) Instead of just a chat we also want to be able to have every peer save a list of jokes and add new jokes. Any peer can add a joke – a user calls "joke" in the terminal, which should be caught by the peer when it detects user input and the peer should ask for the joke. The user enters a joke, which would then be sent to the leader node. The leader node (server of the leader) would then add that joke to its potential list of jokes (make sure it is thread save) and would inform all peers to now also add that joke (would need to send the joke to them). The peers would all (all that are currently available) have to send their ok and save the joke as a potential add-on! Only if all send their ok is the joke actually added. The leader would have to send another "ok now add" (does not have to be that, base it on your protocol) to the peers which would then mean the joke is actually added to the list. If not all of the nodes send their ok, then the joke will be discarded.

We now created a simple consensus, since all nodes need to "agree" on adding the joke. Congratulations

5. We want to be able to start a leader election in case the leader goes off-line.

a) (15 points) Leader election: you can go by highest peer number (if you assign them numbers), go by each peer choosing a random number and comparing that number (smallest, highest wins), go by whoever detect the leader is "dead" tries to become a leader or even Raft (but that is more complicated). Nodes need to communicate and a node can only become a leader by a specified rule you define (explain it in your Readme). See the lecture videos for some suggestions.

b) (3 points) The new leader is now responsible for the handling of the jokes list. If nodes still have potential jokes they will be discarded at this stage.

c) (5 points) Your program needs to be able to handle that any node might not respond (leader or not). Your program should not come to a standstill if a node "dies". If the leader fails a new one needs to be chosen. You should try to set this up as fail-safe as you can, e.g. have the leader send heartbeats if no heartbeat is received the nodes will elect a new leader. If you did the above this hopefully works.

d) (5 points) New nodes can still join the network, they can contact the new leader (though setting the correct leader when calling Gradle)

e) (5 points) New nodes can still join the network by contacting ANY of the nodes and that node will forward the request to the leader (who will then inform everyone about the new peer)

6. (5 points) Overall good error handling, no crashing, users are informed of what is going on.