CMSC 621- Spring 2005
Project
Overview
In this project, you will design and implement a simple Peer-to-Peer distributed file system with digital rights management. The system should allow on demand sharing of files between users based on the digital rights policy of the file. The system will consist of a number of nodes/hosts which are unreliable, in as much as that there is no guarantee that at any given time a particular node will be operational or accessible. Normal operations related to file systems, such as creating, deleting, opening, closing, reading, writing, seeking etc. should be allowed. Replication of the files on different servers should be made based on some replication policy that respects the "Digital Rights" associated with that file. You should attempt to make the replicas as consistent as possible.
Details:
The project can be split into two parts and the grading will be based on
the work done in each of the parts
A. Peer-to-Peer Distributed
File System 50 points
Assume a system with N nodes, and M users. Each of these M users can own a subset of these N nodes. Each user should be able to access any file in the system irrespective of the actual location of the file, provided he has the rights to access that file. For the user the file system should be transparent. Since any of the N nodes may not be available – in order for the system to have high availability (ability to access most of the files irrespective of the number of nodes that currently active) the system should have a replication strategy. Each file created should be copied and stored in more than one node. The number of copies to be created and where to store these copies should be your design choice. The file system should support basic file system operations like open, read, write, delete, append etc. You can assume a uniform namespace (i.e.) the filenames along-with their entire paths will be unique across the system.
For implementing this we suggest you use JXTA a java based peer-to-peer API. We will upload some tutorials for JXTA, and of course Google and the JXTA website remain good sources of further information. If you cannot use JXTA, or would prefer to code in some other language, please discuss this with the instructor.
B. Digital Rights Management 50 points
When a user creates a file – say a music file to be shared in the Peer-to-Peer system - along-with this file, the user also should provide a digital rights management policy. The policy will govern how this file is to be shared – who can access this file, where it can be replicated, who can copy this file etc. Some examples are
1. File A can be shared by a specific subset of the users, but they in-turn should not share it with others.
2. File B can be replicated only in nodes owned by the user and only a given subset of the users can access this file.
3. A file can be open (i.e. music being played) in only one client at a time.
4. A file can be copied by anyone authorized by its owner, but people who copy the file cannot allow others in turn to copy it.
The mechanism of designing and implementing the policies should be addressed in your design. You can refer to several sources on the net for getting an idea of what kind of digital management techniques are used and how they are implemented. We provide some references next. In general, the more "complex" DRM policies you allow, the more credit you get.
For representing the digital rights policy you can come with your own format or use some standard formats. For examples XrML is used for representing digital rights. XACML is a proposed standard from OASIS. The ODRL initiative is also developing a language. UMBC scholars have proposed Rei. The W3C has started a policy development exercise, and several industrial heavyweights have proposed WS-Policy. Your representation of the digital rights will closely follow the management policies you support.
Testing and Validation
Once your design is complete, we expect you to test for the basic file operations as well as tests for validating your rights management policy. The project will have a demo session where based on your design we might ask you to test for a specific case. We expect your system to work for all the scenarios that you have designed it to work for.
Assumptions
The description of the system above, like in real life, is underspecified. You will need to make additional assumptions to come up with a concrete design and implementation. Hence, state your assumptions clearly in you design. Your assumptions will be evaluated based on how it helps your design and how close it resembles real life situations.
Demonstration:
You will submit your code and project report on the due date. No changes will be permitted after this.
Some general suggestions
As should be evident to most of you, it is imperative for a project of this complexity and involving teams that you design your system before you code! In your design, you will need to make assumptions as you flesh in the details of the system. Please make sure that you state them in your design document. Make a timeline for your work, and try and stick to it. Where you divide tasks, make sure you clearly define points of articulation and interfaces between modules. As you form groups, please make sure that you can find a common time to meet. This is especially true for those who are part time students and hold jobs which will restrict your schedule. Please comment your code well -- it will help both you and us. You in figuring out code your partners have written, and us in grading it. Also, use some form of revision control on your source tree. CS/OIT machines have systems such as CVS and RCS available for your use. This will help if lightening strikes, UPC fails and machines/disks crash, making your recent changes disappear! Please do create Makefiles as well, or better still, help your instructor learn about ANTS.
Timelines
|
Initial Design Document |
|
|
Mid Semester status report |
|
|
Final report |
|
What to turn in.
Initial Design
Document
A 2 – 3+ page document detailing your
1. Assumptions
2. Design objective
3. Design
4. Testing strategy
5. Proposed performance evaluation (if any)
5. Timeline
Mid Semester Status
Report
A 3-5 page report detailing your progress, and how it is in tune with your suggested timeline. Design modifications if any (we do not encourage you to make design modifications at this time as we expect you to do all the thinking before the first design document is due) – but if some of your design goals are unattainable this is where you would be telling us. You would be graded accordingly. Change in timelines if any should be suggested here.
Final Report
This should be a 10 – 12 page report detailing your design objectives, implementation details, strengths and weaknesses of your design etc. Testing and performance analysis results for your system – should be reported here.
Grading
Distributed File System part (Part A) – 60 %
Digital Rights Management part (Part B) – 40 %
References
1. Introduction to Digital Rights