The system we will develop will allow file-sharing between heterogeneous machines without requiring a central file server. It will not be a filesystem per se, but will bridge existing filesystems to allow the retrieval of files and directory information from remote machines, maintaining certain file attributes such as creation and modification dates. It will not be limited to a particular machine architecture or operating system, and we will develop POSIX-compliant (Linux) and Win32 (NT) implementations to demonstrate this cross-platform capability. Furthermore, we aim to provide better performance, reliability, and consistency than existing file-sharing systems such as the Windows Network and AppleTalk.

In order to share files on some machine, the PFS daemon must be running on that machine. Typically the daemon will run as a system service. The daemon provides a File Transfer Service, a Membership Service, and a Directory Service. The File Transfer Service allows remote clients to retrieve shared files. The Membership Service allows a user to discover other machines within the local subnet which are running the PFS daemon. The Directory Service allows a user to browse or search remote shared directories.

We will provide a library which will allow the developer of a PFS client application to access the daemon through a well-defined API. We will develop one such client application, a browser which allows a user to browse accessible machines (using the Membership Service), browse directories on those machines and search for exported files (using the Directory Service), and retrieve exported files (using the File Transfer Service). When using a PFS client application (such as the browser), the PFS daemon must be running on the local system in order to use the Membership Service. However, a PFS client may contact a remote daemon even in the absence of a local daemon, though only the File Transfer Service and Directory Service will be available.

The goal of a peer-to-peer file transfer system has been attempted before, namely AppleTalk and Microsoft Network. Our system should distinguish itself from these previous designs in portability, reliability, and scalability. AppleTalk is infamously slow, and it invents proprietary protocols where standards TCP/IP and UDP/IP would be satisfactory, and Microsoft Network is subject to consistency and coherency problems, stale network information, and other problems when certain machines break down.

The user should see machines as they become available and not in a lump sum (in other words, no waving flashlights should ever be shown).

A user should be able to open the browser application, see a dynamic listing of machines on the network, be able to open a machine up, and be able to access files on that machine. If the Membership Service is not running, it should be possible to enter in the name of a machine and access its shared files and directories in the same manner as if someone opened it from the network listing.

A user should also be able to request to search for a file with a given name and have a request be sent to all machines running the Membership Service to search for the specified file. On each machine, the search will be performed locally on that machine eliminating the need to search through individual directories across the network.

• The machines on which our system runs must possess a protocol stack supporting TCP/IP and UDP/IP.
• Our prototype must run on either a POSIX-compliant or Win32 operating system. In theory the system may be implemented on any networked platform.
• The local network must be configured to deliver IP multicasts to some set of local machines, which we will refer to as the "local subnet."

5.1 General

• The system shall be scalable: when the number of participating machines in the system increases, the network traffic generated shall increase linearly.
• The system shall be cross-platform: the protocols and APIs used shall allow the implementation of system components on any networked platform.
• The system shall be reliable: the failure of a subset of participating machines shall not cause lengthy interruptions of service on the remaining machines.

5.2 File Transfer Service

• When contacted by a remote client via a TCP channel with the virtual path to an exported file, the daemon shall return the binary contents of that file.
• The daemon shall translate the virtual path given by a remote client into a path on the local filesystem.

5.3 Directory Service

• When contacted by a remote client via a TCP channel with the virtual path to an exported directory, the daemon shall return a listing of the files in that directory in a well-defined format.
• When contacted by a remote client via a TCP channel with the virtual path to an exported directory and an ASCII string, the daemon shall recursively search the tree based at that directory for files with names identical to the string, and return a listing of those files in a well-defined format.

5.4 Membership Service

• Daemons on participating machines within a local subnet shall cooperate to maintain lists of their identities. The contents of these lists will retain a high degree of consistency and will be updated at fixed intervals.
• A machine which does not respond to a daemon within a fixed interval shall be considered down and removed from that daemon’s list.
• A newly launched daemon will actively seek out the identities of participating machines and will announce its presence.

5.5 Interface Library

• The interface library shall be a statically linked module which abstracts away the details of the communications protocol between a client and a local or remote daemon.

5.6 Browser Application

• The browser shall allow a user to view and retrieve exported files on remote machines.
• The browser shall allow a user to select a remote machine by hostname or IP address.
• The browser shall allow a user to obtain a list of participating machines.
• The browser shall allow a user to search for files on one remote machine or across all participating machines.

PDF Block Diagram

Membership Service:

The Membership Service is a part of the PFS daemon that keeps track of other active PFS clients on a subnet. It can provide machine addresses for a browser application, and it has an interface to the host machine’s network.

File Transfer Service:

This part of the daemon will service transfer requests from remote PFS clients, allowing remote machines to read files off the local machine. It interfaces with the host network.

Directory Service:

The Directory Service is the final section of the PFS daemon. It will service calls for directory information from remote PFS clients and will handle which files are visible to those clients. Other features include a directory search service. It interfaces with the host machine filesystem and the host network to service requests for directory information.

Interface Library:

The Interface Library allows a browser application to call remote PFS daemons without starting its own local daemon. Of course it loses the Membership Service, but this allows the browser to run without sending every request through the PFS daemon. It will call directly into the host network.

Browser Application:

We will implement a browser application to demonstrate the features of the PFS daemon and Interface Library. It will be a GUI that can talk to the daemon and allow the transfer of files from the other machines running the PFS daemon.