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.
- 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.
- View List of Local Files - See Project 1. Make sure your update thread periodically refreshes this list.
- View Contents of Local Files - See Project 1.
- View List of Google Docs Files - See Project 1.
- View Contents of Google Docs Files - See Project 1.
- 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.
- 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.
- Search Local Files - See Project 1.
- Search Remote Files - Allow the user to search the
cached list of remote files. Support the searches specified for
Project 1: contains, matches, modifiedsince.
- 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.
- 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.
- 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.
- For a maximum grade of B, devices will send only information generated by the local update thread.
- 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
- 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
- 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.
a maximum grade of B, statically configure the set of devices, for
example by using a config file that is manually generated by an
- 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.
- 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.
- You will need to define the communication protocol to be used between devices. You may use the existing API where appropriate.
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.
- A demonstration is required for this project. You must demonstrate on or before the class period on 11/18/09.
- Suggested demo script.
Due Wednesday 11/18/09 - 3:30PM