You are required to develop a simple distributed banking system. The banking system is imple- mented using a set of servers, where each server hosts a set of accounts. You can assume that the set of servers in the system and the set of accounts hosted by a server are both static and do not change at run time. The information required to initialize the banking system (e.g., the number of servers, the location of each server, the set of accounts hosted by each server, the initial balance in each account) is stored in a configuration file. A sample configuration file has been provided at the end. Do not change the format of the configuration file without talking to me or the TA!
A user accesses his account using a client program. A client program allows a user to perform one or more of the following tasks:
The first four tasks display the new balance in the appropriate account(s) after the task has been performed. Take suitable precautions to ensure that an account balance never becomes negative. When transferring money, add a random delay between when the money is withdrawn from the source account and when the money is deposited into the destination account to prolong the transfer. Perform the last task by taking a strongly consistent snapshot of the system (i.e., all account values can co-exist at the same time and there are no transfers in progress). You can use the freezing-based protocol discussed in the class to record a strongly consistent snapshot of the system.
You can assume that a client executes tasks serially. For the first three tasks (inquiry, deposit and withdrawal), a client connects to the server that hosts the account involved in the task. For the fourth task, it connects to the server that hosts the account from which the money is being transferred. For the fifth task, it acts as a coordinator responsible for initiating the snapshot protocol and collecting the local states. Note that a client may need to connect to different servers to perform different tasks. Also, to obtain full credit, your system should be able to handle multiple instances of snapshot protocol running concurrently. Also, a client should be able to run in both interactive mode (accept input from the keyboard) as well as batch mode (accept input from a file). A sample input file has also been provided at the end.
Implement a testing mechanism to ascertain that your snapshot protocol indeed yields a strongly consistent snapshot of the system (e.g., using vector time stamps or some other data structure). You will graded on the accuracy and thoroughness of your testing mechanism. You are expected to design the testing mechanism on your own. Please do not ask me or the TA about how to do it!
# A sample configuration file
3 # number of servers
# server set up
# format is (i,j,k) where i is server id, j is host name and k is port number
0 net01.utdallas.edu 31415
1 net02.utdallas.edu 31415
2 net03.utdallas.edu 31625
8 # number of accounts
# account set up
# format is (i,j,k) where i is account number, j is server id and k is initial
# account balance
(0,0,100)
(1,0,200)
(2,0,100)
(3,2,300)
(4,1,250)
(5,2,150)
(6,1,130)
(7,0,110)
# A sample input file for a client
12 # number of tasks
# format is (a,b,c,d,e) where ‘a’ is ‘task type’ (I/D/W/T/S), ‘b’ is ‘from account’,
# ‘c’ is ‘to account’, ‘d’ is ‘amount’
# ‘-’ means not relevant
# Task type codes:
# I: inquiry
# D: deposit
# W: withdrawal
# T: transfer
# S: snapshot
(T,2,7,20)
(W,0,-,25)
(D,1,-,31)
(I,4,-,-)
(D,2,-,30)
(I,1,-,-)
(I,2,-,-)
(T,4,5,29)
(D,6,-,90)
(T,2,6,50)
(D,0,-,25)