Phase II: Bank-Balance Computation
Due: 11:59pm Monday, 10/19/2009
General Instructions.
Students are required to work together in teams.
You may work in the team you used for Phase I or you may form a new team.
An assignment submitted on behalf of a "team" having fewer than 2 or
more than 5 students will receive a grade of F.
All members of the team are responsible for understanding the entire
assignment.
This assignment builds on work done in Phase I.
Feel free to use any team's solution to Phase I as the basis for your
solution to Phase II.
No late assignments will be accepted.
Academic Integrity. Collaboration between groups is
prohibited and will be treated as a violation of the University's
academic integrity code.
Background: Computing a Bank Balance
Once upon a time, banks opened at 9am and closed at 3pm.
This left plenty of time each day for that day's transactions to be processed,
and doing that processing was easy because
the bank's accounts were not being changed by concurrent customer activity.
A 21st Century bank will likely be open to its customers 24 hours a day.
Networked computers should allow transactions to reach the bank's branches from anywhere
in the world that is "wired".
But, suitable protocols must be employed, so that customer transactions can run
concurrently with the bank's back-office daily processing.
In this phase of the cs5410 project, you will program a distributed snapshot algorithm that
computes the assets of the distributed bank implemented for phase I.
Doing the exercise should:
-
Help you to master ideas we have been discussing in class:
consistent cuts and the Chandy-Lamport snapshot algorithm.
-
Give you an opportunity take the description of
an algorithm that might be found in a scientific journal
and translate it to an actual implementation.
-
Force you to contemplate issues associated with testing distributed
protocols.
What to Build
Extend the branch GUI from Phase I
with an additional "button" that allows a user to request an all-bank snapshot.
Activating this button causes a message to be sent to the
local branch server.
That message should lead to taking a global
snapshot of (i) all non-zero account balances at all branches
and (ii) including any in-process Transfer operations.
This global snapshot should be displayed in pieces,
with a separate piece being displayed by the (local) branch GUI for
each of the branches.
Specifically, at each branch, that branch's GUI should display:
-
The list all the accounts having non-zero balance and
maintained by that branch, along with the balance in each.
-
For each communications link (as specified in the network topology file) into
that branch, list all
the funds transfers (including the source and
destination accounts and the amount) in-process when the all-bank snapshot was requested.
Note that, for this application,
snapshot information is not being sent from branch to branch and is not
being assembled at a single process.
You may assume that UDP message delivery is reliable (for purposes
of this phase), but any other guarantees you require
about communications links that connect branches
will have to be discharged by your implementing suitable protocols or
by imposing constraints on the TOPO interconnection topology file.
Fewer constraints are better, however.
Submission Procedure.
All submissions should be made through
CMS.
CMS provides a way for you to
define
your group.
Be advised that each group member must take an action in creating a group,
and your group cannot submit anything through CMS until the group has been created.
Submit the following files (at least):
-
TEAM which contains the names (and net-ids) for all team members.
Also, for each team member give a 1 or 2 paragraph description of the tasks
this team member performed and the number of hours this required.
-
README which contains
- The names and a description of the contents for the other files in the directory.
- Instructions for installing, compiling, and running your software on our
Windows system.
- A tutorial that the grader can follow to start your software and to convince
himself that your system implements the required functionality. Expect the grader
to spend at most 10 minutes on this task.
- The list of authors on the team that developed the Phase I software your
Phase II solution builds on.
-
TOPO should specify an interesting interconnection topology for a multi-branch bank
that will be used to illustrate the operation of your system.
-
TOPOexp should specify what requirements the topology must satisfy in order
for your snapshot algorithm to work correctly.
For example, do you require that every
link be bi-directional?
Obviously, imposing fewer restrictions is better.
-
TestPlan should describe the process and any tools (i.e. additional programs)
you wrote in order to test your system.
-
SourceCode A zip file containing the sources needed to compile and test your system.
Grading.
Your grade will be based on the following elements:
-
Does your system correctly implement the Chandy-Lamport algorithm and compute
consistent cuts for system operation if:
-
(Satisfactory)
At most one snapshot from at most one branch GUI is in progress at any time.
While that snapshot operation runs, new Deposit, Withdraw,
Query, or Transfer operations are delayed
and not processed by branch servers.
-
(Good)
Multiple concurrent snapshots from different branch GUI's can be in progress at any time.
The snapshots each proceed independently.
While the snapshot operation runs, new Deposit, Withdraw,
Query, and Transfer operations are not delayed by branch servers.
-
(Excellent)
Multiple concurrent snapshots from different branch GUI's can be in progress at any time.
The snapshots do not necessarily proceed independently, sharing work when this is
possible.
While the snapshot operation runs, new Deposit, Withdraw,
Query, and Transfer operations are processed by branch servers.
-
How easy is it to follow the README file installation and sample-execution script.
-
How thorough was your testing procedure and how creative you were in building
sufficient scaffolding (test drivers etc) to test your system.
-
Is the source code easy to understand and does it exhibit good structure?
Extra Credit.
In addition to building the system as outlined above, implement
and submit another version that causes all branches to compute and apply
interest to the balances of the accounts they store.
Specifically, extend the branch GUI
with an additional ApplyInterest
"button" that allows a user to request that interest be calculated
and applied to all accounts
at all branches.
Activating this button causes a message to be sent to the local branch server.
That message should lead to the value of every account balance
being multiplied by 1.05
(which corresponds to adding 5% interest to accounts with positive balances and
charging 5% interest to accounts with a negative balance).
In a real bank, there would be restrictions on who can
authorize activation of ApplyInterest and how frequently;
we'll ignore those issues here.
Be warned:
Adding this functionality is a bit tricky.
In particular,
correct handling of Transfer operations
in process when the ApplyInterest button is pressed can be subtle.
Transfer operations must appear to be atomic, so
no Transfer operations should
seem to span an ApplyInterest operation.
That is, each Transfer operation must
either seem to have ocurred before or after (although different
concurrent Transfer operations need not all be ordered the same way)
the interest calculation and updates.