A: The problem

• After the tremendous success of the winter Olympic games, the Gauls are preparing for the summer Olympic games. The summer games are expected to be singificantly more popular and draw more traffic than the winter games. To handle the surge in the number of smart stones accessing sports information, Obelix has decided to replicate the Stone server. Assume that there are now two stone servers that maintain sports scores. A tablet can request a score from either server. Further, motivated by the desire to use the best stone architecture known to humankind in 50BC, Obelix's stone server now employs a multi-tier architecture. This can simply be implemented by maintaining the database tier as a simple file on disk that stores the score and a database tier process that answers for read or write requests to data from the two front end servers. Thus the stone server has at least three processes: two front-end server processes that receive client requests and one backend datbase process that receives read or write requests from the front-end servers. Assume that the front end servers not only receive requests for scores but one of them also receives score updates from the Cacofonix process and then sends an update to the database tier. You only need to implement client-pull for this lab. Server push funcitonality is not needed. Further, while the API exposed by front-end servers is identical to lab 1, you should implement your own internal interface to handle interactions between the front-end and back-end processes (you can deisgn it any way you wish and this interface should be documented in your README file).

  Part 1: Leader election and clock syncronization

  Assume that the two front-end processes and the backend process run a leader election algorithm to elect a time server. You can use any leader election algorithm discussed in class for this purpose. Once a leader has been elected, this node also acts as a time server. Implement the Berkeley clock syncronization algorithm to syncromnize 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 request. Each incoming sports score update is now time-stamped with the syncronized clock value; this time stamp is included with each request for score so that villagers know when the score was last updated.

  Part 2: Logical / vecor clocks

  As the official sponsor of the Olympic games, Rotten Apples Smart Stone Company is running a raffle for each villager who use their smart stones to acccess sports scores. The grand prize is a hunting trip for boars with Asterix, followed by an invitation to the grand feast for the gold medal winners that will be organized by chief Vitalstatistix. Every 100th request to the stone server is automatically entered into the raffle. However the stone server needs to order requests to determine every 100th imcoming request. Since accurate atomic clocks are yet to be invented, we must solve this problem using logical/vector clocks. Here, we assume that clocks on the server processes are not syncronized and yet we wish to determine the ordering of events (here events refer to requests made by clients). To do so, each client process and each front-end server process maintain logical clocks. You can either use Lamports clocks or vector clocks for this purpose. Pick either the totally ordered multicast or causally ordered mutlicast algorithm to determine an ordering of all requests made by the clients to the Pygmy.com front-end servers. Note that in this case, requests must be multicast to all processes, in addition to being sent to the front-end server that will process the request. You are free to design the system with either algorithm. Use the logical clock values to determine the odering of incoming client requests. Again, every 100th request is entered into a raffle. At the end, randomly choose a winner from all raffle entties.

  Like before assume that there are N tablets, each of which is a client, that needs to be periodically updated with sports scores. (N should be configurable in your system).

  Like before, Cacofonix, the village bard, is responsible for providing Obelix's server live updates from the olympic stadium, which he does by singing the scores and thereby sending updated scores to one of the front-end servers.

  Requirements:

  1. You need to implement BOTH Part 1 and Part 2.
  2. All the requirements of Project 1 still apply to Project 2, except that you no longer need to support server push in this part.
• Other requirements:
  No GUIs are required. Simple command line interfaces and textual output of scores and medal tallies are fine.

  You are free to develop your solution on any platform, but please ensure that your programs compile and run on the edlab machines (See note below).

C. What you will submit

1. An electronic copy of the output generated by running your program. Print informative messages when a client or server receives and sends key messages and the scores/medal tallies.
2. A seperate 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). You also need to describe clearly how we can run your program - if we can't run it, we can't verify that it works.
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.

D. Grading policy for all programming assignments

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

Note about edlab machines