A: The problem

• A follow-up on the previous story.

  The trading post model served the Gauls very well at the beginning. However, with the growing popularity of the market, Gauls found that the trader became the new bottleneck. Sellers and buyers needed to wait for a long time to be served. Vitalstatix, the village chief, decreed that henceforth trading post shall be replicated---there shall be two trading posts---a north post and a south post.

  In the new market model, there will be two traders, one at each post. They shall use a common warehouse where all items for sale are stored. Any item that is sold is shipped from the warehouse, while new items that are offered for sale are added to the warehouse. Any trader can take buy or sell requests for any item. Like before, sellers can deposit their goods when the market opens with any trader. Buyers can buy from any trader and the trader will pay the seller after each sale (after deducting a suitable commission). The state of the warehouse is stored centrally, while the traders can cache some portion of this data locally for peformance reasons.

  In addition to buyers, sellers, and the two traders, you need to add a fourth entity to your system: a database server. Our database is simply a file that containts the type and number of items available for sale at the warehouse. The database "server" is a process that can access and update this file; the traders modify the number of items of sale (due to buy and sell requests) via the database server. The database server provides a service to lookup the number of items of a particular type, to decrement and increment the number of items (depending on buy and sell requests). The trader can cache recently acccessed database entries (i.e., item type, number in stock) locally. Cache consistency needs to be addressed, if a locally cached database entry is updated at the database by the other trader.

• This project is based on project 2. Assume that the number of people in the trading post N is specified beforehand (N should be configurable in your system). As usual, each peer is both a client and a server. Each peer should be able to accept multiple requests at the same time. We will ingore ordering based on logical clocks in this assignment (you may still use it, but it is no longer required).

  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 2. A peer can be both a buyer or a seller, or only one of the two. Peers will then elect two coordinators. The peer does not sell or buy anything once it is elected as the coordinator. In this assignments, traders are appointed for "life"---they can not resign once appointed.

  Buyer/seller can randomly choose which trader to do business with.

  Inplement the process that acts as a database server: it should minimally support a lookup for a dataitem (where the number in stock is returned), increment and decrement of items in stock. Implement simple locking to prevent the two traders from concurrently modifying the same item.

  Since traders cache recently accessed entries, choose a suitable cache consistency algorithm based on the ones discussed in class. Strong consistency is needed, since the Gauls are honorable and do not make incorrect buy or sell decisions. The consistency can be achieved either using push or pull and the technique can be stateful or stateless. You have considerable flexibility to make appropriate design decisions.

  For simplicity, the database itself is a single text file with one entry (row) per data item.

• An pictorial representation of the system is as shown in the figure below.
  
  
• The second part of the assignment involves fault tolerance. Should one of elected Gaul traders party too much in the night and fail to show up at their trading post in the morning, we would like the other trader to take over all trading reposibilities. Impelement a simple heartbeat protocol between the traders, where each trader periodically asks the other one are you there? IF no reponse is received within a timeout value, then the other trader is assumed to have failed. In this case, the other trader sends a message to all peers indicating it is now the sole trader and all subsequent messages must be sent to the new trader. Think about how you might handle buy/sell requests that were in progress when the failure occured. Any simple technique that allows you to restart such requests at the other trader are fine so long as the end result is consistent (e.g., a restarted buy request should not yield "duplicate" buy requests at the database server).
• No GUIs are required. Simple command line interfaces are fine.

• Optional Extra Credit Question: In this optional component, we will use cloud computing to dynamically replicate the trader. Intially, Start with one trader (one EC2 server). Monitor the load on the server (in terms of number buy and sell requests seen seen every minute). If the number of requests exceeds a (small) threshold, have the first trader dynamically start a new EC2 server and run a second trader on that machine. All peers must be informed of this new replica and a peer can randomly choose the trader they do business with. No fault tolerance functionality is needed in this extra credit question (Side Note: although not required, do think of a design as to how a failure of a trader allows you to dynamically start a different trader on a separate EC2 server and add a small note to the design document as to how you may have implemented such a functionality).

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 replication (you may simulate a one trader system with your system by letting one trader handle all the requests and another trader be request free). Make necessary plots to support your conclusions.

C. What you will submit

2. 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 via TraderID". 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 intitially (or takes over the duties of a failed one), print a message like " Dear buyers and sellers, My ID is ..., and I am a new coordinator (or I have taken over duties of cordinator N)".
3. 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).
4. A program listing containing in-line documentation.
5. 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.
6. Performance results.
7. 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.