George Mason University

CS571 Operating Systems Spring 2002

Project P2
Report 15 points
Exhibition 5 points

Due 5/1/02

(1) This is a group project. Submit one report for your group. Organize your report as an engineering report that defines the architecture of a system, describes your approach to implementing the components, tests the system, and provides an evaluation of the strengths and weaknesses of the system. The body of your report should not exceed 10 pages. Attach your programs and sample data as appendices. You may present your report as a website.

(2) Use Java as your programming lanuage and environment.

(3) Weights: the written report plus programs 15 points toward final grade; team demo of the working system, another 5 points.

(4) Use these resources:

  • Silberschatz et al chapters 15-17 (distributed computing) and chapters 18-19 (protection and security).
  • Professor Setia's useful links.

A Distributed Storage File System

Consider a distributed system consisting of one or more user workstations, a file server, a directory server, and a print server. The file server stores and accesses files via commands like CREATE, DELETE, OPEN, CLOSE, READ, WRITE. The directory server implements commands like CREATE, DELETE, ENTER, REMOVE, MOVE, and SEARCH. The print server implements commands like PRINT, SHOWQUEUE, and ABORT. Many user application-level programs may need to coordinate more than one server. For example, a shell command like cat infile > outfile will "create outfile" if it does not exist; "create outfile" must create an entry for outfile in the current directory with a handle pointing to the newly created file.

On the user workstation, build a simple command interface that lets you log in and then issue single Unix-style commands with optional arguments and optional input/output redirection, but no pipelines. The set of allowable commands will be very small, just sufficient to permit you to create files, store them in directories, manage directories, and print files.

Implement the workstation command interface, file server, directory server, and print server as distinct Java virtual machines (VM's). The VM's simulate the separate servers. Use the Java Remote Machine Interface (RMI) for communication between the VM's. Set up the simulation so that the VM's can be on different physical machines. Java provides libraries for TCP and RMI.

The file server will know files only by their handles. A user workstation will therefore need to access a directory in order to get a handle to access a file. You can simulate this file server by passing commands through to the host OS file system using Java file classes. You will find it convenient to designate a special host system directory for the file server (e.g., file_server) and use the handles as names in that directory. Thus, choose your handle scheme to be compatible with names that can be stored in your host system. For example, your file handles might take the form "file_001". The file handles will be created by the create command of the file server.

Your directory server will simulate the mapping of names to handles. One way to do this is to map directories to your host system directories, with file-name entries in those directories pointing to small files that contain the file handles. Java has class libraries that you can use to invoke directory commands of your host system.

The print server will maintain a queue of jobs waiting to be printed. The actual printing can be simulated by displaying the print files on your console; no need to use a real printer. You will want to insert delays into the print jobs so that a queue will build up and you can simulate the relative slowness of a real printer.

You don't need to use the exact command names for files and directories as given above. You can use names that match the names used for those functions in your host file and directory systems.

Once you get these components working, create a test suite that demonstrates the operation of all the commands in the distributed system. Capture some samples of the traffic between the servers to demonstrate that the communications between VM's are working properly. Try to include a test where at least one of the servers is on a physically distinct machine.


Extend Your System with Authentication

Once the base system is working, extend it to provide authentication. This will simulate the situation in a real environment, where you want to restrict the use of the network and its servers to authorized users. Authentication will be handled by adding an authentication server (AS) and some protocols to the interactions between your other servers.

Initially, when a user signs on to the workstation, the user communicates with a login protocol. The login protocol asks for username and password. It passes both to the authentication server (AS). The AS returns either an error message or a ticket. The ticket contains a ticket number, a certificate from the AS naming the user and the servers the user is allowed to access, and an expiration time. All accesses to the file, directory, and print servers must be modified to require a valid, unexpired ticket. These servers should refuse to work without a proper ticket. The AS maintains an internal record of logged in users along with a time stamp of the last time the user used a valid ticket; the other servers notify the AS each time a user presents a ticket so that the AS can update this time stamp. The AS considers a user to be automatically logged out if there has been no activity within a logout interval. A user can obtain a ticket with a new expiration time by sending its current ticket to the AS and requesting an update; the AS will grant the update if the user is still logged in, and will request the user to reauthenticate (give password again) otherwise.

In a real system, the initial communication from workstation to AS will be encrypted (to prevent eavesdropping by network packet sniffing) and the ticket will be digitally signed. You do NOT have to implement any of these encryption aspects. We are trying to simulate the function of the authentication tickets without the (important) details of their encryption.

If any of the other servers (file, directory, print) gets an expired ticket, it tells the requestor that the ticket is expired; the requestor must submit the old ticket to the AS and ask for a renewal, which will be issued as long as the AS says the user is still logged in.

When you get this working, create test scripts that show how the system responds to commands when tickets are valid and when they are invalid. Capture the traffic generated by a command to demonstrate that tickets are flowing properly in the system.


Suggestions on Implementation

(1) Start by everyone on the team reading the Silberschatz chapters on distributed computing and security.

(2) Designate one person on your team to be the chief architect -- this person has the final say on what will be implemented and how components built by team members integrate together.

(3) Then implement the base system (workstation, file, directory, and print servers) in Java as outlined above. Create test scripts and capture some inter-server traffic to demonstrate the proper internal flows.

(4) In parallel with step 2, task one member of the team to take the lead to draft the protocols for the AS to use for issuing, validating, and renewing tickets. The whole team must sign off on the protocols.

(5) Extend your base system by adding the authentication protocols. Create test scripts and capture some inter-server traffic to demonstrate the proper internal flow.