A: The problem

You have been tasked to design Pygmy.com - the World's smallest book store. Pygmy.com carries only four books for sale:
1. How to get a good grade in 677 in 20 minutes a day.
2. RPCs for Dummies.
3. Xen and the Art of Surviving Graduate School.
4. Cooking for the Impatient Graduate Student.

Since Pygmy.com hopes to one day become an Amazon, they would like to use sound design principles to design their online store in order to allow for future growth. The store will employ a two tier design - a front-end and a back-end. The front-end tier will accept user requests and perform initial processing. The backend consists of two components: a catalog server and an order server. The catalog server maintains the catalog (which currently consists of the above four entries). For each entry, it maintains the number of items in stock, cost of the book and the topic of the book. Currently all books belong to one of two topics: distributed systems (first two books) and graduate school (the last two books). The order server maintains a list of all orders received for the books.

The front end server supports three operations:

1. search(topic) - which allows the user to specify a topic and returns all entries beloging to that category (a title and an item number are displayed for each match.
2. lookup(item_number) - which allows an item number to be specified and returns details such as number of items in stock and cost
3. buy(item_number) - which specifies an item number for purchase.
The first two operations trigger queries on the catalog server. The buy operations triggers a request to the order server.

The catalog server supports two operations: query and update. Two types of queries are supported: query-by-subject and query-by-item. In the first case, a topic is specified and the server returns all matching entries. In the second case, an item is specified and all relevant details are returned. The update operation allows the cost of an item to be updated or the number of items in stock to be increased or decreased.

The order server supports a single operation: buy(item_number). Upon receiving a buy request, the order server must first verify that the item is in stock by querying the catalog server and then decrement the number of items in stock by one. The buy request can fail if the item is out ot stock. Assume that new stock arrives periodicaly and the catalog is updated accordingly.

An pictorial representation of the system is as shown in the figure below.

• Other requirements:
  Each component can use RPCs or plain sockets.
  Each component 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. For instance, a order server should be able to process multiple concurrent buy requests and decrementing the number of items in stock should be done using synchronization.
  No GUIs are required. Simple command line interfaces are fine.

B. Evaluation and Measurement

1. Compute the average response time per client search request by measuring the response time seen by a client for , say, 1000 sequential requests. Also, measure the response times when multiple clients are concurrently making requests to the system, for instance, you can vary the number of clients and observe how the average response time changes.
2. Following the idea shown above, compute the average response time to buy requests.
3. Design a test to show how the #buy requests affects the average response time to search requests.

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 book, have your program print a message "bought book book_name ". When a client issues a query (lookup/search), having your program print the returned results in a nicely formatted manner.
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.