CS 677 Distributed Operating Systems

Fall 2009

Programming Assignment 2: Whisper.com Part Duex:

Due: Nov 10, 2009

• You may work in groups of two for this lab assignment.
• Purpose of this project is to familiarize you with clock synchronization algorithms, distributed mutual exclusion and leader election algorithms.
• You can be creative with this project. You are free to use any programming languages (C, C++, Java, etc) and any abstractions such as sockets, RPCs, RMIs, threads, events, etc. that might be needed. You have considerable flexibility to make appropriate design decisions and implement them in your program.

A: The problem

Whisper.com is growing in popularity among users. To accommodate the increased load, Whisper.com had replicated its front-end. The architecture now supports two front-end processes, each of which communicates with the backend independently. Clients can communicate with either front-end replica, which then queries to the non-replicated backend to service the user request.

Other than the replicated front-end, all design requirements specified in the first programming assignments still apply.

The assignment has two parts.

---

Part 1: Leader election and clock synchronization First, implement a leader election algorithm, using the ring algorithm, to elect a leader from the two front-end tier processes and the back-end tier database process.

You can be creative as to when elections are triggered. For example, the leader can resign at any time and another leader will need to be chosen.

The leader will be the coordinator for multiple purposes. First, the leader will serve as the time server. Implement the Berkeley clock synchronization algorithm to synchronize their clocks. Each node then maintains a clock-offset variable that is the amount of time by which the clock must be adjusted, as per the Berkeley algorithm. We will not actually adjust the system clock by this value. Rather to timestamp any request, we simply read the current system time, add this offset to the time, and use this adjusted time to timestamp requests.

Every incoming request at each front-end replica is timestamped with the synchronized clock value. This time stamp is used when posting whisps to the database server.

---

Part 2: Distributed mutual exclusion Since multiple front-end replicas can read and write to the database at the same time, we would like to use read-write locks to protect the database access. A read-write lock is a single lock that you can acquire either in read more or write mode. In this part, you will implement a distributed read-write lock using the leader (use the distributed locking protocol discussed in class from this purpose). Each post message requires the front-end process to get a write lock on the database. No other front-end process may access the database for reading or writing when someone holds a write lock. Similarly, a retrieve message requires a read lock on the database. Multiple read-locks can be concurrently held on the database, but no write locks can be granted if at least one process holds a read lock. Thus, read locks allow concurrent access to multiple readers, while write locks only allow mutually exclusive access.

Implement a distributed read-write lock, as specified above, to protect retrieve and post messages for your Whisper.com system.

---

Requirements:

• You need to implement BOTH Part 1 and Part 2.
• All the requirements of Project 1 still apply to Project 2.

---

B. Evaluation and Measurement

1. Compute the average response time (post/retrieve) of your new system as before. How did your implementation of locking impact the response times from assignment 1?
2. Design a test to show how the election processes affect the performance.
3. Design a test to show your clock synchronization algorithm really works expected.
4. Design a test to show that your read-write locks supports multiple readers but only a single writer at any time.

   Make necessary plots to support your conclusions.

---

C. What you will submit

• When you have finished implementing the complete assignment as described above, you will submit your solution in the form of printouts.

• Each program must work correctly and be documented. You should hand in:
  1. A copy of the output generated by running your program. Print informative text messages to describe what each process is doing.

  2. A seperate (typed) document of approximately two pages describing the overall program design, a description of "how it works", and design tradeoffs considered and made. Also describe possible improvements and extensions to your program (and sketch how they might be made).
  3. A program listing containing in-line documentation.
  4. A seperate description of the tests you ran on your program to convince yourself that it is indeed correct. Also describe any cases for which your program is known not to work correctly.
  5. Performance results.
  6. A readme file about how to run your code on EDLAB machines.
  7. After you turn in all the stuff mentioned above, please also send TA an email telling the location of your files .
• Let us not waste a lot of trees. So, if any of the above turn out to be large, just save the relevant information in a file, leave it on your EDLAB account and submit the name of the file.

---

D. Grading policy for all programming assignments

1. Program Listing
   works correctly ------------- 50%
   in-line documentation -------- 15%
2. Design Document
   quality of design ------------ 15%
   understandability of doc ------- 10%
3. Thoroughness of test cases ---------- 10%
4. Grades for late programs will be lowered 12 points per day late.