15-440/640 Spring 2015: Distributed Systems


 


Overview

15-440 is an introductory course in distributed systems. The emphasis will be on the techniques for creating functional, usable, and high-performance distributed systems. To make the issues more concrete, the class includes several multi-week projects requiring significant design and implementation.

The goals of this course are twofold: First, for students to gain an understanding of the principles and techniques behind the design of distributed systems, such as locking, concurrency, scheduling, and communication across the network. Second, for students to gain practical experience designing, implementing, and debugging real distributed systems.

The major themes this course will teach include scarcity, scheduling, concurrency and concurrent programming, naming, abstraction and modularity, imperfect communication and other types of failure, protection from accidental and malicious harm, optimism, and the use of instrumentation and monitoring and debugging tools in problem solving. As the creation and management of software systems is a fundamental goal of any undergraduate systems course, students will design, implement, and debug large programming projects.

Evaluation is based on homeworks, projects, the mid-term exam, and the final exam.

  • Lecture time: 10:30 - 11:50pm, Tuesdays and Thursdays
  • Room: GHC 4401
  • Units: 12
  • Mid-term exam:   Thursday, February 26  in class
  • Final exam:   Tuesday, May 5, 08:30-11:30,   location TBD


Course Instructors

Professors

NameEmailOfficeTelOffice Hours
Mahadev Satyanarayanan   (Satya)
GHC 9123 412-268-3743 Tu  3:00-4:00pm
Padmanabhan Pillai (Babu)
CIC Intel 4th Floor
412-???-???? W 2:00-4:00pm

Teaching Assistants

NameEmailOfficeTelOffice Hours
Ankit Agarwal GHC 5th Floor Teaching Commons

W 5:00-7:00pm
Zhuo Chen GHC 9120
Th 2:00-4:00pm
Iosef Kaver GHC 5th Floor Teaching Commons
M 5:00-7:00pm
Jenny Liao GHC 5th Floor Teaching Commons
M 2:00-4:00 pm
Thomas Marshall GHC 9023
                             
F 1:00-3:00pm
Titouan Rigoudy GHC 5th Floor Teaching Commons
Tu 5:00-7:00pm
Swetha Sankar GHC 5th Floor Teaching Commons
Th 5:00-7:00pm

Course Admin Assistant

Chase Klingensmith, , GHC 9129, Tel: 412-268-3041

Office Hours

See individual entries above.

Course Notes

Will be placed in the course AFS area at:  /afs/andrew/course/15/440/classnotes  after each class.
These notes are for your personal use only.   Please do not distribute them.

Text Books

There are no required textbooks.   Here are two good references to use for optional reading:
  • "Distributed Systems: Principles and Paradigms"   by Andrew S. Tanenbaum and Maarten Van Steen, Second Edition, Prentice Hall
  • "Guide to Reliable Distributed Systems"  by Kenneth P. Birman, Springer

Prerequisites

Because this course has a big project component, you must be proficient in C and Java programming on UNIX systems. It is required that you have taken 15-213 and gotten a "C" or higher since many of the programming skills you will need are taught in that course. If you received a C in 15-213, you must meet with your academic advisor to discuss your background before taking 15-440, perhaps taking an additional course to sharpen your systems skills.

Learning Objectives

After this course, students will have learned to...

  • Implement and structure distributed systems programs.
  • Write programs that can interoperate using well-defined protocols.
  • Debug highly concurrent code that spans multiple programs running on multiple cores and machines.
  • Reason about distributed algorithms for locking, synchronization and concurrency, scheduling, and replication.
  • Use standard network communication primitives such as UDP and TCP.
  • Understand the general properties of networked communication necessary for distributed systems programming in clusters and on the Internet.
  • Employ and create common paradigms for easing the task of distributed systems programming, such as distributed filesystems, RPC, and MapReduce. Be able to clearly elucidate their benefits, drawbacks, and limitations.
  • Identify the security challenges faced by distributed systems programs.
  • Be able to select appropriate security solutions to meet the needs of commonly encountered distributed programming scenarios.

Course Policies

Policy on Academic Integrity

The Carnegie Mellon University Policy on Academic Integrity applies to this course.    All students are expected to carefully review this policy and to adhere to it for all aspects of this course.  Additional information can be found at this helpful CMU web site that explains why academic integrity is so important.

Collaboration

Students are encouraged to talk to each other, to the TAs, to the instructors, or to anyone else about any of the assignments. Any assistance, though, must be limited to discussion of the problem and sketching general approaches to a solution. Each student must write out his or her own solutions to the homework.  All  projects must be done individually.

Consulting another student's solution is prohibited, and submitted solutions may not be copied from any source. These and any other form of collaboration on assignments constitute cheating. If you have any question about whether some activity would constitute cheating, please feel free to ask the instructors.

You may not supply work that you complete during 15-440 to other students in future instances of this course or for use in future instances of this course (just as you may not use work completed by students who've taken the course previously).

No Recordings

No audio or video recordings may be made of the class without the explicit prior permission of the instructor.

Piazza Policy

This course uses the Piazza web site for answering questions. The home Piazza page for this course is at: https://piazza.com/cmu/spring2015/15440/home. When posting questions on Piazza, students must keep in mind the collaboration guidelines noted above, and use those guidelines to determine:

  • Whether to mark your post "private to the instructors" or public;
  • How much detail and help to provide in an answer to a fellow student

Part of the learning process is struggling with the material until you arrive at the right insight for you to understand it. Posting too much detail in response to a request for assistance can impair learning. On the other hand, sometimes it's great to be nudged in the right direction when you're not able to get out of a rut. And, of course, misunderstandings of the assignment or tools available should be helped rapidly. Please use your best judgement when posting to the Piazza site, as if you were collaborating with your friends in person. A few rough guidelines:

  • Please do post and answer publicly: Misunderstandings of the assignment; clarifications about the requirements; bugs in the assignment spec or reference implementation or tests; small, detailed questions about the operation of system calls, functions, etc. Things that look like they'd go in the FAQ are good candidates for asking or answering.
  • Please don't post or answer publicly: More than a few lines of code; in-depth explanations of how your system works; questions about the best approach for architecting the system at a high level; questions about your grade;  etc.

Please use your judgement between these two examples. If you post privately, please let us know whether or not it would be OK to mark the post public if we feel it would be beneficial to the class to make it public.

Think of piazza as raising your hand in class and asking a question.   No question is too stupid to ask, so don't be afraid.    For every person who asks a question, there are probably many others to whom the same question has already arisen or will arise soon.    The answer to your question may benefit them as well.   In addition, there may some people to whom your question did not occur.    By asking the question, you are helping them see a subtlety that they may have not seen before.

Direct email to the instructors will not be answered; use piazza for all class-related communications.  Be cautious about using private piazza posts.   Ask yourself whether the post should be private in the first place.    Do not use private piazza posts as a substitute for attending office hours and asking questions in person. 

We expect you to have made reasonable effort to think for yourself before posting a piazza question (either private or public).  This is especially true with respect to debugging your code.   Did you try the man pages?   Did you do a Google search for possibly relevant resources?   Did you look at the previous questions people have already asked, and at the answers provided?    Did you insert printf's and try to understand what is going on with your code?

Don't use autolab as a debugging tool.  We expect you to have made reasonable effort to get your code debugged before submitting to autolab.  Currently we do not limit the number of times you can submit to autolab, but we may change this if we continue to see autolab being used as a debugging tool.  Creating test cases and stress testing your code is part of what a project is all about.   Without putting in that effort, you are missing an important part of the learning opportunity in the course.    Submission to autolab should be the last step of a process in which you have tested, debugged and improved your code to the furthest extent of your abilities.   Sending an autolab dump in a piazza post and saying "please help" is an egregious violation of piazza etiquette.

Policy on Late Submissions

Each student will have five late days to use throughout the semester. These late days are intended to account for holidays, travel, interviews, a cold, and other similar situations. You are free to use them for any reason, without asking for permission from instructors. You may use at most two late days on any one homework assignment. For projects with multiple checkpoints, you can use up to two late days for each checkpoint.  Late days will be automatically applied in chronological order, so you cannot chose to defer use of a late day for a higher weight future assignment.

One late day = (0,24] hours past the due date; two late days = (24, 48] hours past the due date; etc.    Late days may be used on any assignment unless otherwise specified.

If you use all of your late days, you may submit late for a 15% penalty per day, for up to two days. In other words, if you have used up all your late days, you may still submit for the next two days, incurring a 15% penalty for each of those days.

Contact us if you have extreme circumstances.

Style Guide for Projects

In addition to testing your code's functionality, we will also be reserving a portion of each project's points for its style and readability. The most important thing is a consistent and legible style. We are mostly looking to see that you chose a style that is readable and reasonable, and that you use the same style consistently throughout a project.

Use common sense: don't have 500-character lines of code, don't name your variables (unless that make sense in its context), and avoid mixing case conventions randomly.

We will be looking for the following things:
  • Documentation:  Good documentation is important: for yourself in the future, for other maintainers of the code, and in this context, for the graders who will be looking at your code. Don't feel the need to document every line of code (as good code should also be self-documenting in a sense), but it is usually good to highlight the general usage and purpose of each function, as well as large or complex blocks of code. It is also good practice to include a file header in each file, detailing how that file fits into the structure of the project as a whole.
  • White-space:  Please be consistent. Please don't use tab 2 spaces some places then 4 in others. Be reasonable and use white-space to ensure your code is legible.
  • Line Length:  We will be reasonable about line length, as long as you are consistent and your line limits are reasonable (500 characters is not... 80 or 120 characters is commonly used and accepted).
  • Variable  Names: Your variable names should give a clear indication of what they represent or their usage case.
  • Dead/Test Code:  Try not to submit code that is littered with debug print statements or large commented chunks of code. It decreases readability and distracts from the code that will actually run in production.
  • Design:   Try to design your code and projects in such a way that it is reasonably modular. 5000-line functions are generally a sign of poor design and will give you headaches later.
Source(s) that may be helpful:

Last updated: 2015-02-02-1919 by Satya