

Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
An assignment for a peer-to-peer networks course, given in spring 2008. The assignment is worth 50 points and covers topics such as can topology protection, zipf distribution, and self-stabilizing mutual exclusion algorithms. Students are required to submit typewritten answers with good documentation and reflect their understanding of the topics.
Typology: Assignments
1 / 2
This page cannot be seen from the preview
Don't miss anything!


Assigned March 25 , 2008 , Due April 1 , 2008 , in class Please submit the answers in a typewritten form. Good documentation is essential. Your solution should reflect your own understanding of the topic. Question 1. ( 20 points) Review the topology of CAN. Now, consider an adversary trying to inflict damage into a CAN network. On a 2 D torus, the adversary can completely cut you off by taking down your four neighbors. If you are the architect of CAN. Then what can you do to protect the system from such adversarial attacks that can take down up to k nodes at any time (and k is known to you). Question 2. ( 20 points) Recall Gummadi et al.’s paper (number [ 25 ] in the reading list) on measurements and modeling. Now answer the following questions: (a) What is a Zipf distribution? (b) Why did the Zipf-ian request distribution show a flattened head when web- objects were replaced by immutable objects? (c) What was the impact of a changing client pool (compared to a stagnant client pool?) (d) Why does a shared cache show a low hit ratio when new objects and new users were not added? (e) What does an improved hit ratio mean to the users and the network administrators? Question 3. ( 10 points) We discussed about a self-stabilizing mutual exclusion algorithm in the class. In a unidirectional ring of n processes 0 , 1 , 2 , ... , n- 1 each process can remain in one of the k possible states from the set { 0 , 1 , 2 , ..., k- 1 }. We consider the shared-memory model of computation: A process i , in addition to reading its own state s[i] , can read the state s[i- 1 mod n] of its predecessor process i- 1 mod n. Depending on whether a boolean function (called a guard) of these two states is true, process i may choose to modify its own state. We will call a process with an enabled guard a "privileged process," or a process "holding a token. The ring is in a legal configuration, when the following two conditions hold: 1 The number of processes with an enabled guard is exactly one. 2 In an infinite behavior, a guard of each process is enabled infinitely often. A process executes its critical section, when it has an enabled guard. A process that has an enabled guard but does not want to execute its critical section, simply executes an action to pass the privilege to its neighbor. Transient failures may transform the system to an illegal configuration. The problem is to design a protocol
for stabilization, so that starting from an arbitrary initial state the system eventually converges to a legal configuration, and remains in that configuration thereafter. Dijkstra's solution [ 1 ] assumed process 0 to be a distinguished process that behaves differently from the remaining processes in the ring. All the other processes run identical programs. There is a central scheduler for the entire system. In addition, the condition k > n holds. The programs are as follows: program ring; {program for process 0 } repeat if s[ 0 ] = s[n- 1 ] then s[ 0 ] := s[ 0 ] + 1 mod k forever {program for process i, i! 0 } repeat s[i]! s[i- 1 ] then s[i] := s[i- 1 ] forever We have shown in the class that the system converges to a legal configuration when k
n. Starting from an initial configuration of your choice, show a trace of execution where the system will never converge to a legal configuration when k= 2 and N= 6. Reference. Edsger W. Dijkstra: Self-stabilizing Systems in Spite of Distributed Control. Commun. ACM 17 ( 11 ): 643 - 644 ( 1974 )