A: The problem

• The year is 50 B.C. Gauls, led by Asterix, look forward to challenging the Romans in the latest edition of the ancient Olympic games. Gauls have made tremendous technological progress since the previous olympics and have finally entered the "smart" stone-age. Every Gaul now has a stone tablet that gives them the latest sports scores of their fellow villagers. Each smart-stone (not to be confused with a smart-phone, which are yet to be invented) is updated by Obelix (a sculpter by profession), who has tasked by the village chief to disseminate the latest scores by engraving them onto each stone tablet. You are tasked to design a distributed system using a client-server architecture to efficiently disseminate latest scores to the villagers.

  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).

  First design a client-pull architecture where each client tablet refreshes the medal tally by periodically pulling the latest data from Obelix's stone server. Additionally a client tablet can also request the current score for an ongoing sports event and receive a response from the server.

  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 the server.

• Your system should implement the following interfaces and components:
  1. getMedalTally(teamName), which returns the number of gold, silver and bronze leafs earned by the teamName. You system should track medal tallies for at least two teams, namely Gual and Rome.
  2. incrementMedalTally(teamName,medalTyle) , which increments the medal tally for the specified team, and medalType can be bronze, silver, or gold and the appropriate medal count for that team is incremented.
  3. getScore(eventType), which provides the latest score for the specified eventType. Pick at least three winter Olympics events such as stone Curling and stone skating and provide scores for these events.
  4. setScore(eventType), which updates the current score for the specified event.
  While any stone tablet client can request scores or medal tallies (and can do so concurrently), only the Cacofonix's update process can increment medal tallies and scores in the system. Design each tablet as a separate process, the server is its own process and so is Cacofonix update process. Your client-pull system should be able to handle multiple concurrent requests from different tablets and also concurrent queries and updates. Thus you should use proper synchronization at the server to ensure correctness. You are free to use any server architecture to handle concurrent requests, such as a thread per request model, a pre-spawned pool of threads or event-based architectures.
• Since stone curling is a very popular event among the Gauls, the chief has decreed that a server-push architecture be used to efficiently and immediately disseminate score updates to each tablet. Before a curling event begins, any Gaul interested in receiving push notifications registers with the server. When a curling event is in progress, updates are pushed from the server to all registered tablets whenever any update is received from Cacofonix's update process.
  Your system should implement the following interfaces for server-push mode:
  1. registerClient(clientID, eventType)which registers a client tablet to receive push updates for the specified eventType.
  2. pushUpdate() which pushes an update to all registered clients
  For the push mode, you can implement a separate application to run on the client tablet than the above pull-based application. That is, there is no need to write an integrated client that provides both push and pull functions, although you are certainly allowed (and encouraged) to do so.
• Other requirements:
  IF you use a multi-threaded server, be aware of the thread synchronizing issues to avoid inconsistency, race conditions or deadlock in your system.
  No GUIs are required. Simple command line interfaces and textual output of scores and medal tallies are fine.

B. Evaluation and Measurement

1. Deploy at least 6 clients, a server and an update process. They can be setup on the same machine (different directories) and have the client tablets make several requests and provide the output as part of your submission. Do the same for the server push mode.
2. Next deploy the clients and the server such that at least some of the processes are on different machines and demonstrate that your system works over a network for both client-pull and server-push modes. 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).
3. Conduct a few experiments to evaluate the behavior of your system under different scenarios. Change the rate at which updates are requested, or change the number of clients and measure the latencies to get a reply. In the server push mode, measure how long it takes for the server to push out an update to N clients for different values of N. Report any insights, if any, from your experiments, as to which strategies succeed the best.

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 separate 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 separate 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