This project adds two simple extensions to the previous project. Both will reuse most of the code you wrote for Part I. It's possible that you may not need to do anything in (1) below depending on how you implemented Part I.

1. Part I did not explicitly ask you to uniquely order all transactions in the system, eg, all purchase order numbers could be accompanied with server IDs to make them unique. Since these were only songs, there was no dearth of running out of them. However, now the auditing department is interested in exact ordering of all transactions in the system. So, we want unique integer purchase order numbers assigned to each song such that the order number represents the exact order in which songs were sold in the system. The exact specifications are below:

(a) No two sold songs should have the same order number.

(b) Most of the time, only about 3Q messages (certainly not 5Q) should be used to sell each song. Here Q is the size of the quorum (eg, majority) you use for ordering transactions in the system.

(c) Assume that different servers in the system have different (but fixed) crash frequencies chosen uniformly randomly from once an hour to once a week. Assume recovery time is 30 minutes. Assume that communication delay between any two servers is chosen uniformly randomly between 50 milliseconds and 1 second 99% of the time but can sometimes take arbitrarily long. Choose your quorums such that the response time of transactions is minimized. You can assume no link failures. Hint: for example, you can choose a quorum that consists of just the primary, such a system will be correct but the average response time may be high if the primary is crash-prone.

2. The servers maintain popularity ratings for different songs. Each client assigns a score of between 1 and 10 to any song of their choice by contacting an edge server (typically) close to them and registering their vote. Clients often wish to know which song is the most popular (sum of scores assigned by all clients). So, they ask an edge server or other clients in the system for the answer. Implement a mechanism that satisfies the following conditions:

(a) The answers returned should be sequentially consistent. Note that clients may sometimes contact servers and clients not in their home town.

(b) The client provided answer is either at most 10 seconds stale or no answer is returned. In the latter case, the client contacts an edge server and obtains a fresh answer. Assume all clocks are synchronized to one second precision.

Evaluation: Compare the response time and message complexity of your system with the response time and message complexity in Part I and comment on why you see the difference. Quantify the response time of the querying protocol assuming that a client always first contacts fellow clients located on the same local area network. Show that when query load is high, clients see a significant reduction in response time by querying other local clients as opposed to going to an edge server.

Submission Instructions:

1. Documented code, a script that your TA can use to start up the whole system and test it, and an accompanying README file.

2. A document describing the design of the system and all the assumptions you made. In particular, explain what motivated the choice of quorums in the system.

3. Numbers comparing the average throughput and message complexity of Part I and II(1), and showing the benefit of client-client interaction in (2).

4. A short description of test cases you used to convince yourself that your system works correctly.