CS 677 Distributed Operating Systems

Spring 2005

Programming Assignment 1: A Centralized Bank Account Manager

Due: March 11th - in class

(for off-campus students - 14 days after viewing Lecture 8 )

• You may work in groups of two for this lab assignment.
• A link to a FAQ for this project. The link will be updated to answer common questions about the assignment.
• Here are some useful references for this project.

1 The Problem

In this programming assignment you are to implement a Centralized Multi-User Concurrent Bank Account Manager. The system has two important components:

1. Bank Server
   The server program that services online requests for account manipulations and maintains all customer records correctly.
2. Clients
   Customers are clients of the bank server and use its services to update bank accounts. The operations that can be performed on an account are: withdrawl of an amount from an account and deposit of an amount into an account. Additionally, the bank server can have it's own service that periodically deposits an interest amount to each account based on some fixed rate.

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

1. Server
   The server receives queries from customers (ATM clients, Clients/Billing agencies performing online transactions etc.) for operations on accounts.
   The server should have the following functionalities:
   
   • Should be able to accept multiple concurrent customer requests (i.e., must be multi-threaded)
   • It should provide locking/protection for access to an account records during shared access (i.e., a user might be depositing money into his account and at the same time a online billing agent might be withdrawing money from the same account). Such cases need to be correctly handled by protecting variables in the critical section.
   • Maintain correctness of records at each record, (i.e., allow withdrawl from an account only if it has sufficient funds etc)
   • To create a set of records at the server initially, you can use an input file that the server reads and creates account information.
     An example input file format could be:

     	 101 Peter 16000
     	 102 John  1200
     	 103 Gambo 11000
     	 .
     	 .
     	 .
     	 

     The format for each line being: account number, name, balance amount
2. Client
   A client issues requests to the server from a transaction based on account numbers.
   Client functionality:
   • Issue withdrawl or deposit requests.
   • For ease of testing and to make experiments bigger, the clients can issue requests at fixed time intervals. A client can read an input file for transaction information and perform those tasks accordingly.
     For example, following is a format you can use to generate input for each client and use it in experiments.

     	 10 101 w 200
     	 25 101 d 300
     	 26 105 d 150
     	 .
     	 .
     	 .
     	 

     Each line of the input file is a transaction request to be issued by the client and has the following format: timestamp, account number, transaction type(withdrawl/deposit), amount
   • Should receive status of transaction from server and print or log status for each.

You can be creative with this project. (like add create new online accounts, which means add new functionalities, other than mentioned above, at both client and server etc.)
You are free to use any programming languages (C, C++, Java, etc) and any abstractions such as sockets, RPCs, RMIs, threads, events, etc. that might be needed.

Some things to keep in mind:

• The server should be able to handle multiple transaction 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.
• The server should provide protection for shared simultaneous access to the same record using semaphores or locks etc.
• No GUIs are required. Simple command line interfaces are fine.
• You can work in groups of two for this assignment.

2 Evaluation and Measurement

Correctness
Demonstrate that your system works correctly according to requirements stated in the description of the system.

1. Show that the server preserves correctness of transactions by deducting money only when available, is multi-threaded and accepts requests concurrently.
2. Show use of locks/semaphores that protects simultaneous access to the same account. i.e., design a test experiment(s) to demonstrate this using logs or message display during events.

1. Use a set of periodic requests at each client (e.g., each sending a request every 2 secs) and vary the number of clients connected to the server. Measure the average time to complete each transaction for each client. Plot a graph to show average time to complete each transaction as number of clients are increased (say from 1 to 100).
2. The same experiment can be repeated by fixing the number for clients (to say 25) and then varying the request rate. i.e., one request every 0.1,0.2,...1 secs etc. Measure and plot the average time to complete each transaction as the request rate is varied.

3 What you will submit

When you have finished implementing the complete assignment as described above, put all the code in a separate directory in your edlab account (/677/project1).

You are required to submit your solution in the form of printouts.

Each program must work correctly and be documented. You should hand in:

1. A copy of the output generated by running your program. When the sensor proxy receives data, have your program print a message "data received from source s" . When a sink is sent data by the proxy server, have your program print messages for the data being sent by the proxy and for the data being received by the sink.
2. A separate (typed) document of approximately two pages describing the overall program design, a description of "how it works", and design tradeoffs considered and made. Describe clearly how multiple threads and synchronization are handled. Also describe possible improvements and extensions to your program (and sketch how they might be made).
3. Prepare a list of design considerations you made while designing your system and describe each briefly. This is similar to the design considerations discussed in class of the Email system on the last slide of Lecture 2.
4. A program listing containing in-line documentation.
5. Instructions to compile and run the code from 677/project1.
6. 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.
7. Performance results.

Let us not waste a lot of trees. So, if any of the above turn out to be large, just save the relevant information in a file, leave it on your EDLAB account and submit the name of the file.

4 Grading policy for all programming assignments

Grading:

• Program Listing
  • works correctly ------------- 50%
  • in-line documentation -------- 15%
• Design Document
  • quality of design ------------ 15%
  • understandability of doc ------- 10%
• Thoroughness evaluation ---------- 10%

Grades for late programs will be lowered 12 points per day late.