Phase V: Optional Enhancement Phase

Due: 11:59pm Friday, 12/4/2009

General Instructions. Students are required to work together in teams. You may work in a team you used for an earlier phase or you may form a new team. An assignment submitted on behalf of a "team" having fewer than 2 or more than 5 students will receive a grade of F. All members of the team are responsible for understanding the entire assignment.

This assignment expects you to extend your work on some prior phase. Feel free to use code or ideas from any team's solution to any prior phases in designing that extension. However, submissions that contain extraneous code (such as code needed for implementing earlier phases but not needed in this phase) will be penalized.

No late assignments will be accepted.

Academic Integrity. Collaboration between groups is prohibited and will be treated as a violation of the University's academic integrity code.

Background: Optional Enhancement Phase

For example, if you do not submit a solution to phase V and you earned a grade of B on phase II, B+ on phase III, and A- on phase IV then your phase V grade would be B+. But if you submit a solution to phase V, earn a grade of B, and have grades of B on phase II, B+ on phase III, and A- on phase IV then your phase V grade will be worse (B) than it would have been (B+).

Your grade in phase V depends on (i) how ambitious you are and (ii) how well you achieve those ambitious. A trivial enhancement -- no matter how well built -- will not receive a strong grade. In order to help avoid trivial enhancements, you are required to get prior approval for the problem you propose to attack. The process for phase V thus involves four separate steps, each of which must be completed by the time indicated:

• 8am, Monday, Nov 23. One member of a group submits to the CMS assignment "Phase V Prop" a .txt file of at most 1 page (and not a .doc or .htm file):
  • A brief description of the enhancement that your group will undertake. The description should be a few paragraphs, at most. Use the "Background" and "What to Build" sections of our prior project descriptions as a model for what needs to be said.
  • The list of students who will be working together on this phase.
  Part of the challenge in this phase is to assess what tasks are feasible and worthwhile given your group's capabilities. Therefore, the course staff is not permitted to discuss or help with the content of your proposal prior to the submission date.

• 12 noon, Wednesday Nov 25. The course staff will use email to inform the member of the group who submitted the enhancement proposal whether we deem it suitable. Given scheduling constraints, this decision must be final; it is not subject to review or negotiation.

• 11:59pm Friday, Dec 4. Submit completed project to CMS.

• Week of Dec 7. Meet with course staff for at most an hour to demonstrate your system and undertake a design review and code review of your implementation.

To be clear on the ground rules:

• Making a Nov 25 submission does not obligate the group to submit a phase V.

• A group may submit a phase V project only if the proposal submitted on Nov 25 was deemed acceptable.

• A project submitted to CMS on Dec 4 will be graded and will count---whether it causes your grade to increase or decrease.

What to Build

Here are some examples of possible enhancements, any one of which we are certain to deem acceptable.

1. Add fault-tolerance to phase I by implementing some sort of message-logging protocol.
2. Implement a reliable failure-detector (or "master" for chain replication) for crash failures, and use that in your solution to phase III.
3. Implement the PAXOS agreement protocol for crash failures (in asynchronous systems) and use this to support the state machines in phase IV. (But implementing some other, arbitrary consensus protocol for asynchronous settings is not likely to be deemed non-trivial.)
4. Implement a clock synchronization protocol for crash or byzantine failures and use this to support an ordering protocol for state machines in phase IV.

Submission Procedure. All submissions should be made through CMS. CMS provides a way for you to define your group. Be advised that each group member must take an action in creating a group, and your group cannot submit anything through CMS until the group has been created.

Submit the following files:

TEAM a .txt file that contains the names (and net-ids) for all team members. Also, for each team member give a 1 or 2 paragraph description of the tasks this team member performed and the number of hours this required.

README a .txt file that contains sufficient information for us to understand what you built and why it works. Include citations to the papers in any literature (including the textbook) you consulted in designing your protocol. Also include detailed instructions so that we can build, install, and run your system on our Windows machine.

SourceCode A zip file containing the sources needed to compile and test your system.

Grading. Your grade will be based on the above documentation and the following elements:

• Does your system run.

• How hostile is the computing environment you target? More hostile environments lead to better grades only if the system runs. Thus, you are strongly encouraged to choose a computing environment initially for which the chances of your getting the system to run are reasonably good; then, if you have more time, consider extending your system to run in a more hostile environment.

• How easy is it to follow the README file installation and sample-execution script.

• Is the source code easy to understand and does it exhibit good structure?

• Any additional impressions we get from meeting with the group (during the Week of Dec 7) about the design, code, and operation of your system.