15-441: Assignments

There will be three programming projects and (roughly) 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 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.

Assignment	Assigned	Due	Notes	Solutions
Project 1	8/27/14	Checkpoint 1: 9/5/14 Checkpoint 2: 9/19/14 Checkpoint 3: 10/3/14
Homework 1	9/8/14	9/16/14 1:30 PM in class		Solution
Homework 2	10/1/14	10/10/14		Solution
Project 2	10/7/14	Checkpoint 1: 10/20/13 Final Submission: 11/3/13	Starter Code FAQ
Homework 3	11/4/14	11/13/14		Solution
Project 3	11/7/13	Checkpoint 1: 11/21/13 Final Submission: 12/5/13	Info, Updates, and Starter Code
Homework 4	11/27/14	12/4/14		Solution

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.

Notes on the 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 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 systems programming is to be able to work in teams, we projects 2 and 3 are team projects. Also, you need to use version control (git for the project) to manage the shared code base.
An important part of system programming is to develop comprehensive test methods for the programs. While we will give you some example tests for the project checkpoints (in the form of scripts or autograders for autolab), grading of the projects will be based on a more extensive set of tests. For this reason, 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 Piazza . Other students likely have the same questions you do. If you don't find your question, don't be shy about posting. (But please keep your questions high-level; don't post your code.)
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 but rather 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.