A: The problem

• At the very beginning, the bazaar served the Gauls well. However, with the growing popularity of the bazaar, there were too many whispers that got lost in the din. After a town meeting, Vitalstatix, the village chief, decreed that henceforth the bazaar will adapt a trading post model. The Guals will use a leader election algorithm to elect a trader, who will be in charge of the trading post. All sellers will deposit their good when the market opens with the trader. Buyers will buy from the trader and the trader will pay the seller after each sale (after deducting a suitable commission).

  A trader can resign her post at any time; or may call in sick. In this case, the market should elect a new leader. The trader maintains meticulous accounts, so the current state of the market (number of good available for sale, pending sales) are not lost when a new trader is elected. Use a disk file to maintain these accounts.

  While in the bazaar model, concurrent buy requests for the last item on sale were resolved randomly, the trading post has adopted a charter to be fair to all buyers. Accordingly, all buyers and sellers have a logical clock (digital timepieces are yet to be invented, so logical clocks are the only option). Logical clocks are used to order buy events, and if there is only one item remaining, then concurrent buy requests are resolved using clock values. You need to decide whether to equip each Gaul with a Lamport or Vector clock.
  Sellers can offer new items for sale any time: like before, the item type (salt, fish, boar) and the number of items available is specified to the trader. Buyers need to specify what item and how many they wish to buy. As per the fair trading charter, purchase prices are determined a priori and are not negotiable. Upon each sale, the appropriate seller is credited with the purchase price.

• Assume that the number of people in the trading post N is specified beforehand (N should be configurable in your system).

  First construct an connected network. Assume that a list of all N peers and their addresses/ports are specified in a configuration file.

  Once the network is formed, randomly assign a seller or buyer role to each peer following the description of project 1. A peer can be both a buyer or a seller, or only one of the two. Peers will then elect a coordinator using any election method mentioned in the class. The peer does not sell or buy anything once it is elected as the coordinator. If the current coordinator resigns, a new round of election will be triggered. We can assume that the last coordinator will write all the useful information to a file so that the new coordinator can read such information from the file.

  Each peer maintains a clock. The clock is used to decide which seller to do business with, once multiple responses are received. In this assignment, you may implement either Lamport logical clocks or vector clocks.

• As in Project 1, each peer is both a client and a server.

  Each peer should be able to accept multiple requests at the same time. This could be easily done using threads. Be aware of the thread synchronizing issues to avoid inconsistency or deadlock in your system.

• No GUIs are required. Simple command line interfaces are fine.

B. Evaluation and Measurement

1. Deploy at least 6 peers. They can be setup on the same machine (different directories) or different machines.
2. Do a simple experiment study to evaluate the behavior of your system. Compute the average response time per client search request by measuring the response time seen by a client for, say, 1000 sequential requests. Also, observe the performance change due to the coordinator re-election. Make necessary plots to support your conclusions.
3. Next run some of your peers on a remote Ec2 servers and the rest on local machine(s). Force your leader election to choose a peer on EC2 as the coordinator (this can be done, for instance, by running a few peers on EC2 and giving them higher number IDs - which will cause leader election to choose an EC2 peer as the coordinator). Repeat the experiment and comment on how your measurements change due to WAN latencies between some of the peers. Instructions on accessing EC2 servers to run your experiments are here

C. What you will submit

1. A copy of the output generated by running your program. When it receives a product, have your program print a message "bought product_name from peerID". When a peer issues a query, having your program print the returned results in a nicely formatted manner including the local time that the result is received. When a new coordinator is elected, print a message like " Dear buyers and sellers, My ID is ..., and I am the new coordinator".
2. A seperate document/file 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.

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.