15-440 Assignments

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

Project 3 final reviews

Please sign up for a 30 minute slot with one of the course staff:

• Prof. Andersen (T 10:30-12:30, 2-4pm; wed 1:30-3:30; Fri 1:30- 4)
• Prof. Bryant (Tues 9-10, 3-4; Wed 9-10; Fri 3-4)
• Iulian (Tues 2:30pm-5pm; Wed 2pm-5:30pm; Fri 10am-12pm)
• Ravi (Tues 3:30pm-4:30pm, Wed 12:00pm-2:00pm, Thu 9:00am-10:30am)

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-440 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.

Programming in Go

• The language is type-safe and garbage collected, avoiding many of the pitfalls of lower-level languages, such as C and C++
• Many useful data structures are built into the language, such as resizable arrays and dictionaries.
• There is a large collection of packages providing access to useful system resources.
• Go supports a model of concurrency that is cleaner and more abstract than traditional mechanisms, such as Pthreads and Java threads.

You can get your own copy of Go from the installation site. Alternatively, you can use a version we installed on AFS from any campus Linux machine (either CS or Andrew). To do so, add the following lines to the .cshrc file in your home directory:

• setenv PATH /afs/cs.cmu.edu/academic/class/15440-f11/go/bin:$PATH
• setenv GOROOT /afs/cs.cmu.edu/academic/class/15440-f11/go

• (add-to-list 'load-path "/afs/cs.cmu.edu/academic/class/15440-f11/go/misc/emacs" t)
• (require 'go-mode-load)

• The main Go website contains extensive documentation. Especially useful are:
  • The web document titled Effective Go
  • The language specification
  • The package documentation
• The online book Network Programming with Go by Jan Newmarch. Especially useful is Chapter 3, where they show sample code using TCP and UDP sockets.

General Notes on the Programming Projects

A key objective of this course 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:

• Although it was historically done in a low-level language, such as C, to ensure close control over system resources, it is now increasingly common to see systems written using type-safe languages with dynamically-allocated data structures, such as Java and Go, to increase reliability and to reduce the vulnerability to attacks, such as buffer-overflow exploits.
• 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.
• Distributed systems nearly always involve 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 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 slightly incomplete 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 completely 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 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: Mon Dec 12 16:10:49 -0500 2011 [validate xhtml]