General Instructions. Students should work together according to the teams formed in Phase 0. 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. Within a group, we expect all members to do their share and team members can help one-another out.
All the communication between servers will use UDP. You'll implement protocols from Part III of the book to replicate the data managed by the server so that you can demonstrate the ability to tolerate crashes. Then you'll measure performance and explore options for load-balancing and scaling the system up, so that the replication mechanisms used for fault-tolerance also bring a benefit of better scalability. But we're starting small, and these fancy server-to-server mechanisms will come in a second stage of the project. Right now you just need to support a routing infrastructure that will get messages from branch to branch over the unidirectional communication links defined by the connectivity graph you'll read as an input at startup time.
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:
As noted above, we'll be using a cluster-styled server in Phase II and beyond, and will be interconnecting the clusters. Just to anticipate:
Notice that all of these options work equally well when a program is executed multiple times on a single computer or when it is executed once each on multiple computers connected by a network. A single machine could even run a whole server cluster. This will let you do development on a single machine or on a set of side-by-side machines in the CSUG lab.
You can visualize the bank's client systems as leaves on a tree or some other kind of connected graph, each linked to its local branch. The "nodes" to which the clients link are the members of a branch server cluster (perhaps just a single process, but perhaps multiple processes sharing replicated data for availability and scalability).
Don't assume that the graph is a simple rooted tree. To make our project a bit more interesting, we'll work with a connected graph, in which the links aren't even bi-directional. We recognize that this is a bit arbitrary, but it will let you gain experience with some mechanisms you might not otherwise have a chance to implement, like distributed routing algorithms.
Structuring the Phase I bank server. Structure your distributed bank as follows. Implement each branch as two C# or Java applications --- a branch server and a branch GUI. A client computer will run the branch GUI application, which communicates (only) with its branch server. In contrast, branch servers directly communicate with other branch servers. Most of the complexity of our project will be in the branch server applications.
Associated with each branch server is a pair of network addresses to which messages destined to that branch server can be sent. One of these network addresses will correspond to a TCP socket bound to an IP address and a port number for use by Web Services clients (namely, the branch GUI). The other will be a UDP socket bound to a different port number, for use in communication between branches. In these assignments, when we talk about UDP communication between branches, we'll write B.ServPort to denote the network address associated with the branch server B for inter-server communication. This UDP socket will be created and managed by you as a programmer, in contrast to the Web Services address, which is generated automatically and hence less visible to the programmer. Read about the UdpClient class to learn how to create and use this UDP socket.
One implication of this architecture that is even though we'll eventually be implementing our branches using clusters of servers, the cluster as a whole will still be accessed through just a single "load balancing" front end. Thus, once you start to deal with load-balancing, it will be necessary to redirect incoming Web Services requests from this single network address to an appropriate server within the cluster, so as to keep loads uniform. When we get to that stage, we'll solve the problem using the same mechanisms used by commercial datacenters. However, in Phase I we won't be implementing clustering, so this is just something to keep in mind for later.
We would like you to use Web Services as the client-to-server communication standard. Within C#, you can do this by pulling the ASP.NET template onto your application inside the Visual Studio C# programming environment; it will ask questions to guide you through the setup and you'll have a chance to tell it to use TCP, etc. Later, the option of reprogramming the client to server communication protocol to run over UDP is something you may want to consider; initially, though, we'll be content with the normal HTTP over TCP "default" provided by ASP.NET if you just let it do things in the most standard way.
If the Internet Information Service (IIS) is running on your server computer you can use the Web Services discovery mechanisms in client systems. But we know that not all machines are set up with IIS enabled. If IIS is not enabled on your machine, clients should still be able to access the server if you know the IP address to use (have the server check and display it somehow, then type it in on the client machine) and the port number (either pick a number, or let Windows assign one and type that in too).
Inter-Branch Communication Limitations. We're initially going to work with a single server for each branch. Communication between these branches is constrained to follow a given network topology (a weird constraint, but one that makes the problem more interesting). 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. 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. Moreover, you can assume that there exists some "route" from any server Bi to any other server Bj. A route may require that messages be forwarded through some other branch; this routing is something you'll need to implement.
To ensure that your servers can't violate the restrictions in the topology file, simulate the limitations that the network topology imposes on inter-branch communication by writing a 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 C#'s operation for performing a UDP send, UdpClient.Send.
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 C# applications to be built.
Adhering to the above specified structure (branch server, branch GUI, Web Services network communication from GUI to server and UDP from server to server, and use of the branch server wrapper class) is necessary so that your implementation will be usable in subsequent phases of the project.
set PATH=g:\jdk1.2.2\bin;%PATH%.
You can then run all the JAVA binaries directly from the shell.
Submission Procedure. Create a directory containing the files you wish us to grade. Using the "Winzip" application, compress the contents of this directory into a single archive and email Vivek the archive with a reminder of who the team members are.
Should you wish to revise your submission after you have emailed it to Vivek, simply correct the files and resend the entire archive. We'll grade the last submission we receive and will discard older ones. No late submissions will be graded, so please get things in on time.
Your directory should contain the following files (at least):
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? 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: