15-441 Assignments

There will be three programming projects and four written homework assignments.

All homework and the first project is to be done individually. The second and third programming projects will be done in groups of two students.

The later projects are done in groups for two reasons. The first is the size of the class. The second and more important reason is that this is an opportunity to experience the joys and frustrations of working with others. It's a skill you only get better at with practice.

Since 15-441 fulfills the project-class requirement of the CS degree, you will be expected to learn and practice good software engineering, as well as demonstrate mastery of the networking concepts. Both partners in a project group will need to fully understand the project and your solution in order to do well on those exam questions relating to the projects. For example, a typical question might be: "When you implemented X, you came across a particular situation Y that required some care. Explain why this simple solution Z doesn't work and describe how you solved it." We'll pick questions such that it will take some effort to figure out Y. If you didn't take the time to work the problem yourself and just relied on your partner, you won't have enough time during the test to figure it out. Be careful, the insights you'll need will come only from actually solving the problem as opposed to just seeing the solution.

By their nature, the assignments aren't going to be completely comprehensive of everything you'll encounter in the real world or in class. To assist you, we've compiled a list of suggested study problems that you may want to do in addition to the normal homework. They're not graded, but they'd make great topics to discuss with the course staff during office hours.

Notes on the 15-441 Programming Projects

A key objective of 15-441 is to provide a significant experience with system programming, where you must write programs that are robust and that must integrate with a large, installed software base. Oftentimes, these programs are the ones that other people will build upon or use as tools. Systems programming is very different from the application program development you have done in earlier courses:

• It is typically done in a low-level language, such as C, to ensure close control over system resources.
• Especially with server code, it must be designed to run indefinitely. It must handle reliably handle every possible error condition, and it must manage resources such as memory with care.
• It must be secure. Connecting a system to a network makes it vulnerable to malicious attacks initiated anywhere in the world. Poorly designed or implemented network software provides a common entrypoint for attack. System software must be invulnerable to flaws such as string overflows or malformed incoming messages. (This point bears repeating: Any system software must stringently check input it receives from the network or from the user. Do not trust either one! They're often out to get you.)
• The interfaces to other parts of the system are generally specified by documented protocols.
• Networking software typically involves concurrency, both within individual machines (multiple processes or threads) as well as among the different network components.
• An important part of system programming is to develop comprehensive test methods for the programs. A significant effort should be invested in writing programs that will thoroughly test the system code, including the handling of different error conditions.

Finally, please note that by design, the 15-441 projects do not always specify every corner case bit of behavior or every design decision you may have to make. A major challenge in implementing real systems is in making the leap from a specification that is often somewhat incomplete (e.g., the IRC spec) to a real-world implementation. Don't get frustrated -- our grading will not dock you for making reasonable design decisions! We suggest three general guidelines to follow:

• Be conservative in what you do, be liberal in what you accept from others.. This is the design guideline underlying many Internet services, first uttered as a robustness principle by Jon Postel in the first TCP RFC, RFC 793.
• Browse the newsgroup and FAQ, ask the course staff!
• Make a reasonable design decision and document it. In a perfect world, all aspects of a design would be comletely specified, but most real-world, large, complex systems do not achieve this goal. You will often hear the course staff reply: You may pick either alternative as long as your server does not crash. This advice applies particularly to error handling, where there are a nearly infinite number of possible errors with partially-specified error responses. The goal of the course is to gain experience with creating large systems; we don't expect students to be psychic, merely to exercise good judgement about creating a robust and usable system.

We'll go into more detail about each of these points during the recitation sections. But keep in mind: The programming assignments in 15-441 are larger and more open-ended than in other courses. Doing a good job on the project requires more than just producing code that runs: it should have a good overall organization, be well implemented and documented, and be thoroughly tested.

Last updated: Sun May 02 19:31:40 -0400 2010 [validate xhtml]