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. Logical clock is used to decide which person to do business with, once multiple responses are received.

  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. We will ignore trader failures in this assignment.

  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.
  
  

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

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 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, print a message like " Dear buyers and sellers, My ID is ..., and I am a new coordinator".
2. A seperate (typed) 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).
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 on EDLAB machines.
7. After you turn in all the stuff mentioned above, please also send TA an email telling the location of your files .

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.