Homework 4: Transactional Account Management

Assignment given: April 8, 2008
Due Date: April 28, 2008 by 10pm

You are free to implement this homework in C or in Java or in a combination of the two. It is very important that you dedicate serious effort to the design of your programs. The design document must be submitted by Friday April 18 at 10pm. It will receive 0 to 10 points. The actual program, due on Monday April 28 at 10pm, will receive from 0 to 20 points.

In this homework we will develop a transactional account management system for a small bank. The bank maintains a number of accounts. For simplicity we assume that there is a fixed number of accounts, say N, and the accountIds are 0, 1, .., N-1. For each account it keeps only the balance (a double) in the account. The information about the accounts is kept in text files account0.txt, account1.txt, ..

Clients request only one kind of operation: 

	transfer fromAccountId toAccoutId amount
Each client will be a copy of the same program. The client in a loop sends (UDP) to the Server a request of the form 
	transactionId fromAccount toAccount amount\n
and waits for a reply (UDP) of the form 
	transactionId 1     in case of success, i.e. transfer took place
or
	transactionId 0     in case of failure, i.e. transfer was not 
			    feasible (insufficient balance)
If no reply is received within a specified deadline (say 30 seconds) the transaction is assumed to have failed. If it receives a response, is sends back a confirmation consisting just of the transaction-id. In either case it waits one second, then sends the next request. Each client will store in a log its timestamped requests and corresponding replies.

Each request is generated at random (fromAccount is randomly chosen in 0 to N-1, toAccount is randomly chosen in 0 to N-1 excluding fromAccount, amount is a positive double. As for the transactionId, it consists of an integer identifying the client followed, separated by '-', by the value returned by the time system call when the request is made - the client id is passed as command line parameter when the client is launched).

The Server is a multithreaded Server that will have to interact with many clients (at least 2). When a thread carries out a transfer request from account A to account B, it will with some small probability terminate abruptly the Server.

The Server must be so designed, with a companion Restarter program, that the clients need to know nothing about Server failures except for some small delays. The Restarter program has as its only purpose to determine if the Server is alive, and if not, to restart it. Since the Server can terminate in the middle of a transfer operation, i.e. it may have done a withdrawal on one account without doing a deposit on the other, you will need to keep persistent information to allow the Server to complete or abort the transaction when it is restarted.

Return to your TA a single tar file with your programs, your data file(s), make file, and description.