Home

Projects

Publications

Resume

nfs_server.c ftp.c dirinfo.c connlist.c
fhandle.c fileCache.c nfsmount_server.c cache.c
rpcutil.c nfs_svc.c nfs_xdr.c

The project files are written for Microsoft VC++ version 4.0 and have only been tested on Windows 95. In order to run the server, it is also necessary to run pm_ascii.exe which is included in the RPC package. The RPC package we used was ONCRPC which can be downloaded from: http://set.gmd.de/~mfg/oncrpc.htm.

Project Motivation.

A large inconvenience of being a CS major at Princeton is trying to maintain files on both a CS account and a regular CIT account which is issued to every Princeton student. Since the CS staff does not permit NFS mounts across the firewall, the only way to transfer files is through FTP. This can be quite combersome, especially if there are a many files.

Project Concept.

Our project fixes the inconveniences of FTP by implementing a unique NFS server which will communicate to other file systems via FTP. Using our system, users can mount directories in their CS accounts to file systems which they would normally connect to using ftp, like the CIT file servers. After mounting the directory appears to be a regular directory, and the user can take advantage of all of the regular file system commands to transfer files, read files, and even run emacs on them. Behind the scenes, our NFS server is maintaining a FTP connection to the mounted site and fetching all the requested data through FTP commands.

Project Goals.

Our goals for this project were to implement an NFS server which could be mounted from a CS machine and also maintain an FTP connection which will be used for handling the NFS requests. These connections can be made to any Unix-based machine on the Internet which supports FTP.

Implementation Issues

We knew that our NFS server could not be run on any of the CIT Unix machines since running an NFS server requires root access. Fortunately (for us), this is not true on some of the CS machines. We also did not want to have to write both an NFS sever and an FTP client from scratch as well as all of the code in between to make it all work. Therefore, we looked into existing public domain code which we could use for our project. Fortunately, the code for WS_FTP32 is publicly available and in implemented for Windows 95. Also Sun's RPC communication libraries were also publicly available for Win95. As a result, our project was implemented for Windows 95. We were able to strip out and modify all of the basic FTP connection code from WS_FTP32 to make a useful abstract interface to FTP which can be used with any Windows 95 application.

With these two key parts of the project already existing we set ahead to write the remainder. First, the NFS server needed to be written. The specification for NFS provided enough information to write the XDR definition file for RPC. With this in place, running rpcgen created all of the source files to implement the NFS server routines.

How NFS works: NFS references all files by a unique 32 byte file handle for each file. Requests on a file, like read, write, or get attributes all are referenced through this file handle. There is no concept of a current working directory. File handles are obtained through a lookup command which is passed the file handle of the directory which it is in and the name of the file. There are additional functions for listing directories, removing, deleting, creating, and renameing a file. Also links are supported under NFS with seperate commands for creating and getting the reference of the link.

How FTP works: Unlike NFS which uses RPC for all of its communication, FTP is a text based protocol. There are basic commands like LIST, which lists a directory, RETR and STOR will get retrive a file and store a file. Commands like USER and PASS to login. MKD and RMD will make and remove directories

Division of Labor:

Given the dual nature of our project it was easy to divide up the work between two people. Ian worked primarily on getting the NFS stuff to work, Joe worked on getting the FTP stuff to work. We worked together to integrate these two pieces to form one single system, which is NfsFtp.

Limitations:

Combining NFS to work with FTP required some limitation on what is supported for our NFS server. For example, FTP only returns the of output of a certain set of commands, such as ls -l, so we were limited by these commands in the information we could obtain. Thus, the information available to us to send back to the NFS client was somewhat limited. For example, things like creation time are not properly represented on the NFS client.

Furthermore, FTP does not supply any "read block" type of command which will allow us to only fetch a part of the file. NFS however, does most of its reading and writing in 8Kb blocks. Therefore to read the first 100 bytes of a file, FTP must download the entire file before it can look at it. This limitation is accepted and doesn't restrict the functionallity of the NFS server, only the response time.

Caching:

Caching becomes nessesary when working with an NFS server since commands like "ls -l" on the NFS client get translated into a call to getattributes for every file. A cacheless implementation would have to do an FTP list on the directory and parse the returned text for the file attributes. This would be a tremendous amount of overhead just so the user could see all of the file sizes in that directory. As a result, a cache is kept of the last directory listing looked up, so that a command like "ls -l" only will execute a single FTP LIST command.

Files also need to be cached. The read and write functions are passed the offset into the file and the amount of data to be transfered which is limited to 8Kb by the NFS protocol. This means that in order to read a large file, the NFS command Read is called repeatatly to get the whole file. If there were no caching, a seperate FTP RETR command would have to get the whole file even though it only needs part of it. We maintain a two file LRU cache to provide optimal performance on commands like cp within the remote file system. All writes are write-through to the FTP file server.

How NfsFtp works:

Leaving the NfsFtp server running on a Win95 machine, CS users can login to hart.cs.princeton.edu and type:

 "mount server.machine:ftpserver:username:password dirname" 

This will make dirname a normal directory with all of the NFS commands associated with that name space sent to the NfsFtp server for handling.

The NfsFtp server runs a seperate mount rpc service which receives the mount request and opens the connection to the FTP server. All the file system commands are sent to the NFS server running on the machine. File handles are maintained in a large queue which stores information about the file, such as the full path of the file, a pointer to the directory it is in and its 32 byte identifier. These are assigned through an NFS lookup call. All file system commands are referenced by the file handle.

Results:

A lot of time was spent debugging Windows sockets and incomplete specifications, but we were able to get a working implementation done with all the desired functionality. It supports flawless transfer of both binary and ASCII files. Additionally, we are able to support multiple mounts to different sites by different users. The original specification was only for a single-user system, but we expanded the model to allow multiple connections. However, since it was not in the original specification, it has not been as thoroughly tested as single-user use. But, all of the tests that we did perform succeeded flawlessly.

The system works quite well and much faster than we had expected it to, particularly once we implemented caching. It integrates nicely into the file system, allowing for such benefits as tab-completion and the like. We were also able to view and edit a remote file through emacs. All in all, we consider this project to be quite a success.