Due Wednesday 11/18/09 - 3:30PM

The goal of this project is to extend Project 1 to allow a user to access metadata about files stored on any of his/her computers and to provide a backup and restore service for a user's data.

Functionality

1. Login - The user must use his/her Google credentials to log in to your application.  You do not need to support multiple users in this iteration of the project.
   
2. View List of Local Files - See Project 1.  Make sure your update thread periodically refreshes this list.
   
3. View Contents of Local Files - See Project 1.
   
4. View List of Google Docs Files - See Project 1.
   
5. View Contents of Google Docs Files - See Project 1.
   
6. View List of Remote Files - The user may select any of his/her devices and see a list of files available on that device.  Note, you will serve cached information that is potentially stale.
   
7. View Contents of Remote Files - If the remote device is online, allow the user to view files stored on that device.  Optionally, serve cached versions of the requested files.
   
8. Search Local Files - See Project 1.
   
9. Search Remote Files - Allow the user to search the cached list of remote files.  Support the searches specified for Project 1: contains, matches, modifiedsince.
   
10. Backup Local Files - Allow the user to request that local files be backed up on other devices.  The user will specify the desired number of replicas.  Your service will, in the background, choose N other devices and send a copy of the file to those devices.
11. Restore Files - Allow the user to restore a file that has been deleted locally, but that was backed up before it was deleted.  If the user asks to restore a file, your server will contact one of the devices on which the file has been backed up, and will download the file and put it back in its original location.  

Requirements

1. Metadata Replication - Devices will use a push-based mechanism to exchange FileList information .  Periodically, each online device will send its own information to all of the other devices in the system.
   
1. For a maximum grade of B, devices will send only information generated by the local update thread.
2. For full credit, devices may exchange information received by other devices.  In other words, you will support the following scenario: device A sends its local information to device B while device C is offline.  Device A goes offline and, later, device C comes online.  Device B sends its local information to device C, and also sends the information it has cached from device A.  To fully support this scenario, you will need to ensure that newer data is not overwritten by older data, for example by using Lamport timestamps for versioning.
   
2. Data Replication - A user may specify the number of replicas he/she wants to create for a particular file.  If the user has requested more replicas than there are online devices, your service will create as many replicas as possible at the time of the request, and create new replicas as other devices come online.
   
3. Discovery - You must implement a mechanism for devices to discover one another.  Conceptually, the system is made up of several devices (i.e., all of the devices in a user's collection or a set of devices supporting multiple users but under a single administrative domain).  The devices in the system maintain a neighbor table with the IP addresses of the other devices in the system. 
   
1. For a maximum grade of B, statically configure the set of devices, for example by using a config file that is manually generated by an administrator.
2. For full credit, implement a solution that allows devices to be dynamically added to the system.  One option is to implement a name server.  Each device is statically configured with the IP address of the name server.  Devices register with the name server when they come online and may ask the name server for a list of devices in the system.
   
3. For extra credit, support secure communication among devices by using your name server as a certificate authority (CA).  Each device in the system is statically configured with a key it can use to communicate with the CA via SSL.  Each device has a public/private key pair.  When it registeres with the CA, it sends it public key, which can be retrieved by other devices in the system.  To communicate securely with another device, a device retrieves a public key from the CA. 

Other Notes

1. You will need to define the communication protocol to be used between devices.  You may use the existing API where appropriate.
2. You will need to decide how and where you will store replicas.  For example, you might allow the user to configure the "Backup" directory where other devices may store replicas.
3. A demonstration is required for this project.  You must demonstrate on or before the class period on 11/18/09.
4. Suggested demo script .
   

Due Wednesday 11/18/09 - 3:30PM