Project 6. A prototype for a Stateless File Server and its Cache Mechanisms

Download the zipped documents of this page.

Introduction

This project concerns the design and implementation of a simple stateless file server and its client-side API. It will give you experience in the use of TCP for communication between client and server and in the design of a client-side cache. Your system will tested with a weather forecast database which is potentially very large.

The specification of the coursework is to found here.

The interface of the client-side API (which you should implement) is provided below, together with a default client and a data file with which you can test your software.

Java Files for Coursework

Basic APIs

The Java interface for the client API for the file system in Section 2.2.1 of the specification is given in the file fileSystemAPI.java and the subsidiary definition of the class filehandle is given in the file filehandle.java. The program in the file checkfh.java can be used to chack whether the filehandle class works correctly.
The client program in testClient.java is for testing the communication between your client API and the file server. The program arguments specify the IP address and port of the server and the file name. The program repeatedly calls the read operation in the client API to get the weather forecast data from the file server. It includes timing statements allowing you to measure the performance of your client-server inetraction.

Test Data

A small smaple of weather forecast data is supplied in the file data.txt

The file fileSystem.java provides a simple example implementation of the client API of the file system. It provides the operations open,, read etc. on a local file. These must be replaced by operations that communicate by means of TCP with the file server. The file testCl.java is a version of testClient.java that works with this simple implementation - it supplies open with the name of a local file (the IP address and port are not required). You can compile and run these tests with data in a local file, for example: java testCl data.txt.

A set of questions and answers can be found in the FAQ.

Additional Notes

1) Report

Please write a report which clearly describes the design of your software. In particular, if your design deviates from the specification please document this carefully. It is very important for me to know whether the design is well-thought out or not.

Other points:

• Point out clearly in the report any good features: a good workng cache, concurrency control,  error handling, etc. These points will be considered when marking.
• I hope your codes are decently commented, but first of all try to prepare a readable report.
• If you made efforts on design but have not been able to make your code run, you can still submit a report describing your design as concretely as possible. Although I will not be able to offer high marks, this does count.
   

2) Document how to run your code

You should document how your software can be run. In particular, note the following points. In testing, the test for reading is emphasised since this is mainly about caching. Separately I will also check the writing function.

(a) If you use TCP, I need to run a  server-side file system, and we need to compile a client using your Client-side file system. If possible, use the name

          fileSystem.java

(which implements, as default, fileSystemAPI)  for your client-side FS. If you hard-wire IP, directory etc., that is OK but write a note on this.

(b) If you use RMI, we need to run a server-side file system as a remote object. It also needs a registry. So document how both can be run (well you CAN let your registry run somewhere beforehand, if you like). For the client side, try to use the name

       fileSystem.java

as what implements fileSystemAPI (as default). Again, if you hardwire data, write a note on it.
 

3) Generally on Design.

There are quite a few questions about design decisions, for example about how a client-side write should work w.r.t. caching. As I wrote in the specification, write-through (as written in the textbook) is one way, but alternatively, you can write to cache and then "flush" later. Other options exist. Any reasonable design is fine, but document well what your system does.