Phase I: Distributed Banking System

Due: 9:00am Monday, Oct. 1, 2001

General Instructions. Students are required to work together according to the teams formed in Phase 0. An assignment submitted on behalf of a "group" having fewer than 3 or more than 5 students will receive a grade of F. All members of the group are responsible for understanding the entire assignment.

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: Building a Distributed Banking System

Our bank comprises a set of branches. Each branch manages a disjoint subset of the bank's accounts. Associated with each account is a unique account number, a balance, as well as other information that will be of less concern to us.

Customers may invoke the following operations on accounts:

• Deposit( acnt, amt ): Cause the balance of account number acnt to be increased by the specified amount amt. Returns the new account balance.

• Withdraw( acnt, amt ): Cause the balance of account number acnt to be decreased by specified amount amt. Returns the new (possibly negative) account balance.

• Query( acnt ): Returns the balance of account number acnt.

• Transfer( src_acnt, dest_acnt, amt ): Cause the balance of account number src_acnt to be decreased by amt and the balance of account number dest_acnt to be increased by amt. Returns the new (possibly negative) account balance of account number src_acnt.

What to Build

• that communication between branches is accomplished only by using UDP (unreliable datagram protocol), and
• that each branch can directly communicate only with the subset of branches defined to be its neighbors according to the network topology.

Structure your distributed bank as follows. Implement each branch as two JAVA applications --- a branch server and a branch GUI. A branch GUI communicates (only) with its branch server, controlling its behavior; branch servers directly communicate with other branch servers.

Associated with each branch server is a single unique network address to which messages destined to that branch server can be sent; associated with each branch GUI is also a single unique network address to which messages destined to that branch GUI can be sent. (Each of these network addresses will correspond to a distinct UDP socket.) For a branch B, we write B.ServPort to denote the network address associated with the branch server and we write B.GUIPort to denote the network address associated with the branch GUI.

Inter-Branch Communication Limitations. Communication between branches is likely constrained to follow some given network topology. Therefore, construct your system to accept as an additional input the fixed, static, interconnection graph that defines which branches can send messages to which others. This graph should be input from a text file. Each line of that file should have the form

B1 B2

where B1 and B2 are names of branches; such a line in the file would assert that the network topology allows B1 to send messages to B2.

For this first phase of the project, the network topology might have uni-directional connections. Thus, just because branch B1 can send to B2 this does not imply that branch B2 can send to B1. However, you may assume that all branch servers have access to identical copies of this file, so all agree on the network topology for the system.

Simulate the limitations that the network topology imposes on inter-branch communication by writing a Java class that branches must use to send messages. This "wrapper" class (so named because it encapsulates network communications operations) should limit the allowed use of Java's operation for performing a UDP send, DatagramSocket.send.

Whenever the wrapped send operation at a given branch B is invoked, the wrapper checks to see if the destination address corresponds to a branch that is directly reachable from B (by consulting the interconnection graph).

• IF the destination is reachable THEN the real UDP operation DatagramSocket.send is invoked for the named socket.
• IF the destination is not directly reachable THEN the wrapped send does not invoke DatagramSocket.send but does return an error-code to the invoker of the wrapped send operation.

Your wrapper class should also introduce a new operation --- whoNeighbors --- which returns the names of all branches that are directly reachable (along one edge of the interconnection graph) from the invoker.

Account Numbers. You may assume that account numbers are of the form bb.aaaaa where bb is a 2-digit numeric value that designates a branch and aaaaa is a 5-digit numeric value that identifies an individual account within that branch. Also assume that an account comes into being (with a 0 balance) by virtue of any invocation of any operation that names that account number --- an assumption that is unrealistic but will nevertheless eliminate the possibility of operations on undefined accounts.

Client and Server: Branch GUI and Branch Server. Here, then, are descriptions of the two JAVA applications to be built.

• BranchGUI creates a window on the console. This window should allow invocation of Deposit, Withdraw, and Query operations for any account managed by that branch; the window should also allow invocation of a Transfer operations involving a src_acnt managed by that branch and a dest_acnt that is managed by an adjacent branch.

  BranchGUI at a branch B communicates with the associated banch server using UDP, directing messages to B.ServPort. Replies from the branch server are sent to B.GUIPort.

• BranchServer receives messages on B.ServPort. Messages from BranchGUI will specify operations that the server should perform on accounts. These messages should be processed one at a time, in the sequence they are received. Operations Deposit, Withdraw, and Query are local and, therefore, reasonably straightforward. Operation Transfer need be supported only when src_acnt is managed by the current branch and dest_acnt is managed by a branch that is directly reachable from the current branch. Ignore other Transfer operations. A supported Transfer operation can therefore be implemented by (i) doing a local Withdraw and then (ii) that branch server sending a message to B'.ServPort for the branch B' that manages dest_acnt so that the appropriate Deposit occurs.

Note, adhering to the above specified structure (branch server, branch GUI, B.GUIPort and B.ServPort, UDP network communcation, and branch server wrapper class) is necessary so that your implementation will be usable in subsequent phases of the project.

Implementation Notes

• Develop your system under Windows/NT --- not on a SUN. This will enable your applications to use any TCP and UDP port numbers bigger than 1000 without risk of interference with other applications sharing the processor.

  JAVA in the Undergraduate Lab can be found in the path g:\jdk1.2.2\bin. To use JAVA, open a CMD shell and set the PATH to point to the JAVA binaries with the command

  set PATH=g:\jdk1.2.2\bin;%PATH%.

  You can then run all the JAVA binaries directly from the shell.

• To learn about programming of GUI and network Java applications, you will undoubtely find the JavaSoft Java tutorial to be useful. In particular, the following lessons (or trails) should prove instructive:
  • Networking for general information on network programming in Java.
  • All About Datagrams for information on UDP.
  • Creating a GUI for how to create GUI applications.
  You will want to study carefully the discussion of UDP sockets and their communication operations: send and receive methods.

• With at least three people in a team, an obvious way to partition this assignment is for a different person to take the lead on (i) the branch server, (ii) the branch GUI, and (iii) the network wrapper class. But recall that everyone must understand the operation of the entire system once it is submitted for grading.

Submission Procedure. Create a directory containing the files you wish us to grade. Call this directory xxxxx0, where xxxxx is the Cornell network id of the team member whose net id is alphabetically smallest of your team. Then copy this directory to the following folder:

\\Goose\courses\cs514-fall01\proj01.submit

Don't be disturbed by warnings informing you that the file cannot be accessed after it has been copied.

Should you wish to revise your submission after you have copied it to our folder, then simply correct the files and recopy the entire directory---but this time use the name xxxxx1. Revisions to that should be named xxxxx2, and so on. We will grade only the largest-numbered file of a series. No late submissions will be accepted.

Your directory should contain 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-NT 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.

TOPO should specify an interesting interconnection topology for a multi-branch bank that will be used to illustrate the operation of your system.

JAVA source file that contain the Java source needed to compile and run your system.

Don't underestimate what is involved in writing instructions for installing, compiling, and running your software. Do path values have to be set? Must the software be installed in a particular directory? Must the name of the host processor be put someplace? Use one group member's account to test your installation script. The easier it is to install your system, the more-kindly disposed the grader will be in evaluating your efforts.

Grading. Your grade will be based on the following elements:

• Does your system satisfy the requirements on system-structure outlined above?
• Does the system operate correctly?
• How easy is it to follow the README file installation and sample-execution script.
• How completely does the sample-execution script exercise your system.
• Is the source code easy to understand and does it exhibit good structure?