G22.3033-010 Final project

Overview

1. Project proposal. The proposal is a short (maximum of two pages) proposal for what your project will be. It should state what problem you are solving, why you are solving it, what software you will write, and what the expected results will be. You won't be judged on your proposal; it is there to help you to get started.
2. Software demo. You will execute the project and demonstrate the software to me.
3. Project paper. The paper is a maximum of 12 pages in at least 11 point font, describing the problem you solved and the solution, and reporting how effective that solution was. The paper should have a serious evaluation section, similar to the ones that you have seen in the research papers you are reading in class.
4. Presentation. You will present your work to the class in a talk on the last day of classes. (Probably a 20 minute talk with 10 minutes of questions.)

Doing a good project is a daunting task. In general, it is better to tackle a precise small problem and do a good job evaluating it than to tackle a large problem and get lost in the scope of the problem. To help you to define a project, this page lists several suggestions.

You should keep me informed at all stages of your project. Please come talk to me about your idea for a project, how you should execute the project, what resources you need for the project, what you should write about in your final paper, etc.

The project should be executed in teams of 1-3 students. The larger the team, the more ambitious your project should be. When you have formed a team, send me email to set up a meeting and discuss your proposed project.

Project suggestions

• Design a disk layout for a file system and implement it in an SFS server. Make sure your layout and update algorithms have good crash recovery properties.

• Design and build an on-disk file system representation consisting of just a B-tree. You probably want to modify sfsusrv to make calls to a B-tree package such as Berkeley DB rather than (as currently) to the UNIX file system. Your challenges are (1) to figure out how to make the NFS operations efficient using the B-tree and (2) to make crash recovery work well. You can view this as an elegant simplification of the SGI XFS file system.

• Design and build an encrypting file system.

• Implement the world's fastest web proxy with persistent caching. Use NFS as an asynchronous interface to the file system.

• Implement a threaded web proxy and analyze the performance. Compare threaded vs. asynchronous performance.

• Build a mail proxy that rejects spam. It's easy to get spam by posting to newsgroups. Post fake articles from fake email addresses, and record any mail sent to those addresses as spam. Then reject any mail messages almost identical to the spam.

• Implement a system for dynamic caching of data on untrusted machines. The SFSRO read-only file system digitally signs data so clients needn't trust the server. This would allow clients to get data from each other without trusting each other. However a mechanism is required for clients to find out about and transfer data from each other.

• Build a file system to something else gateway (e.g. ftp, database, web).

• The eraser tool finds data races in threaded programs. It uses link-time code modification to rewrite executables, and thus is not portable. Implement a portable race detector using C++ templates (ptr, ref, etc.) to detect when memory is referenced.

• Propose a new buffer management strategy and instrument a file system to evaluate it.

• Design and evaluate a scheme for dynamically organizing data on disk to optimize reads. For example, many web pages contain several images. Disk throughput would be improved if a web page and all its images were near each other on disk. This could be achieved by reorganizing disk layout based on reads (particularly if there are more disks than the system needs storage). Design such a disk-reorganization scheme and evaluate it using traces from a web server.

The Paper

Suggestions on Writing Style

Your paper should be as long as is necessary to explain the problem, your solution, the reasons for your choices, and your analysis of your solution. It should be no longer than that. The body of your paper must not exceed twelve 11-point, single-spaced pages in length. Please use 1-inch margins. In general, your paper's style and arrangement should be similar to the papers we've read in class.

A good paper begins with an abstract. The abstract is a very short summary of the entire paper. It is not an outline of the organization of the paper! It states the problem to be addressed (in one sentence). It states the essential points of your solution, without any detailed justification. And it announces any conclusions you have drawn. Good abstracts can fit in 100-150 words, at most.

The body of your paper should expand the points made in the abstract. Here you should:

1. Introduce the problem and the externally imposed constraints.
2. State the goals of your solution clearly.
3. Describe the design of your solution. You may wish to divide the description into a high level architecture and a set of lower-level implementation decisions. This would be a good place for pictures and diagrams.
4. Analyze how well the system you built fulfils your goals. Depending on your system, the analysis might deal with performance in the sense of throughput or running time; but keep in mind that factors such as reliability and useability may be as or more important goals than performance for some systems.
5. Briefly review related work in the area of your project. The goal is to show either how you extended existing work or how you improved on it.
6. Conclude with a review of lessons to be learned from your work.
7. Document your sources, giving a list of all references (including personal communications). The style of your citations (references) and bibliography should be similar to the styles in the technical papers you're reading in this class. In particular, a bibliography at the end and no citations in the text of your paper is insufficient; You should show what specific pieces of information you learned from where.

Write for an audience that understands basic O/S and network concepts and has a fair amount of experience applying them in various situations, but has not thought carefully about the particular problem you are dealing with.

How will your paper be graded?

Your paper will be graded on both content and writing.

Some content considerations:

• Do you provide motivation for why the problem you chose is worthwhile or interesting?
• Does your solution address the goals you stated?
• Do you explain your decisions and the trade-offs?
• How complex is your solution? Simple is better, yet sometimes simple won't do the job. But unnecessary complexity is bad.
• Does your solution fit well with the rest of the system? If your solution requires modifying every piece of hardware, software, and data in sight, it won't be credible, unless you can come up with a very good story why everything needs to be changed.
• Is your analysis clear?

• Is the report easy to comprehend?
• Is it well organized and coherent?
• Does it use diagrams where appropriate? (A frequent problem when people use word processors is that they try to express everything in words, either because the word processor doesn't make it easy to include diagrams, or they haven't ever learned how to use the drawing features. Pictures can communicate some ideas far better.)
• Does it use the concepts, models, and terminology used in the course? If not, does it have a good reason for using a different universe of discourse?
• Is there a good abstract and bibliography?

Make sure you save enough time to write a good paper, since that's what will determine your grade!