|
CSEP 552: PMP Distributed Systems,
Winter 2016
|
|
Overview
Instructor:
Dan Ports
Office hours: Monday 5pm-6pm, in CSE468, or by appointment.
TA: Haichen Shen
Office hours: by appointment
(send email to haichen at cs dot washington dot edu)
TA: Adriana Szekeres
Office hours: by appointment
(send email to aaasz at cs dot washington dot edu)
Lectures: Tuesday, 6:30pm-9:20pm, in THO 125.
CSEP552 is a graduate course on distributed systems. Distributed
systems have become central to many aspects of how computers are used,
from web applications to e-commerce to content distribution. This
course will cover abstractions and implementation techniques for the
construction of distributed systems, including client server
computing, the web, cloud computing, peer-to-peer systems, and
distributed storage systems. Topics will include remote procedure
call, maintaining consistency of distributed state, fault tolerance,
high availability, and other topics. As we believe the best way to
learn the material is to build it, there will be a series of
hands-on programming projects.
Prerequisities: the basic prerequisite is to have taken an
undergraduate operating systems course (CSE
451 or equivalent) or an undergraduate networking course (CSE
461 or equivalent). If you haven't taken an undergrad OS or
networks course, please come talk to Dan. We will not be
covering undergraduate material in this course.
Papers: you will be responsible for reading approximately three
papers before each class, and contributing your thoughts on the
assigned papers to the class discussion board before the class that
covers it.
Projects: every few weeks, I'll hand out a programming
assignment related to the course material. You will work on the
programming assignments solo.
Grading: Course grades will be based primarily on the
programming assignments (80%), along with participation in the
discussion board (20%). The course is not curved.
Mailing list: When you register for the course, you'll
automatically be added to the class mailing list
(csep552a_wi16@uw.edu). To manage your subscription, visit
the mailing
list web page. You will be subscribed using your
u.washington.edu email address, but you can modify your
subscription to use an email address of your choice. Note that you
can only post to the mailing list from your subscribed email address.
Announcements:
- [February 15] We've extended the Lab
3A and 3B due dates from Wednesday to the following Sundays, Feb
21st and 28th respectively. Please note that the Lab 4 due dates
remain as is and we can't accept late days on those, so please plan
accordingly.
- [February 12] On Feb 16th, we'll have
a guest lecture from Swami Sivasubramanian from Amazon about lessons
learned from Dynamo. As a result, we'll be holding class in MOR 220. Amazon is
also providing dinner at 5pm in the same location.
- [January 26] As announced in lecture
today, we're shifting the Lab 2A due date to Sunday, January
31st. Note that Lab 2B is still due the following Sunday, Feb 7th.
- [January 6] By popular demand, we've
moved assignment due dates that were on Fridays to Sunday. There is
at least one weekend per assignment (if not more), to ensure that we
can accommodate work schedules. We've also clarified the late
policy and grading.
- [January 1] Due to high enrollment,
we've moved lectures to a larger room. They will be held in
Thomson 125.
- [December 30] Please read through the
papers due on Tuesday before coming to our first lecture. Hopefully
you'll find them to be a quick read!
- [December 30] Here is a link to an
anonymous email form that you can use to send Dan anonymous
feedback about the course. Use it to give us suggestions,
comments, or constructive criticism.
Here's the link to the class discussion board:
https://catalyst.uw.edu/gopost/board/drkp/41436/
The discussion board has three areas:
- Announcements. I'll cross-post any announcements on this
web page and the class discussion board.
- Paper discussions. For each lecture other than the
first, we will post a small set of discussion questions based on the
assigned papers. You're required to add a unique comment to the
discussion of one of the questions by noon on the day of the
class. (This is to give time for everyone to read the discussion
entries before class.) Note that the earlier you post, the easier it
is to be unique. Please keep your entries short: they can be
anything that provides insight into the question being asked. We
grade posts on a two point scale: solid, or pro forma. If you say
something particularly insightful, we'll give you extra credit
(i.e., 3 points). We'll drop the two lowest scores during the
quarter.
- General course discussion. This is a great place for you
to post questions about papers, programming assignments or design
exercises, or anything else
class-related.
Here is the schedule of papers for the quarter; this schedule might be
tweaked as we progress. The discussion board entries for the
assigned papers are due by noon on the day of the associated lecture.
The core of the course is to build a highly available, scalable, fault
tolerant NoSQL key-value storage systems. Key-value stores are widely
used in practice, and face many of the key challenges of distributed
systems design. In the project, you'll use techniques drawn from the
readings and lectures, e.g. state machine replication and Paxos
consensus, to tackle these challenges..
You'll implement this lab (and all the labs)
in Go. Go is particularly convenient
for writing this type of code. If you don't have any experience
working with Go, don't worry -- the first lab is intended (in part) to
get you up to speed on Go programming. We've provided links to some
helpful resources about Go below.
- Lab 1
out: Friday, January 1st, 2016
due: Sunday, January 17th, 2016, by 9pm
- Lab 2
out: Wednesday, January 13th, 2016
part A due: Wednesday, January 27th Sunday, January 31st 2016, by 9pm
part B due: Sunday, February 7th 2016, by 9pm
- Lab 3
out: Thursday, February 4th, 2016
part A due: Wednesday, February 17th 2016 Sunday, February 21st 2016, by 9pm
part B due: Wednesday, February 24th 2016, Sunday, February 28th 2016 by 9pm
- Lab 4
out: Friday, February 19th, 2016
parts A and B due: Wednesday, March 16th 2016, by 9pm
Submission: Please submit your labs as a tarball to the
Catalyst dropbox. Detailed
submission instructions
are here.
Late policy: We will allow a total of 5 slack days for all
assignments; you can use and distribute them between the labs in
whatever way is most convenient for you. Slack days cannot be used for
Lab 4 (because of end-of-quarter deadlines). Once you have exhausted
your allocation of 5 slack days, we will deduct 10% of the grade for
an assignment for each day that it is submitted late.
You should be able to complete the labs on any machine that can run Go
programs. In practice, you'll probably want to use your own personal
machines; none of them require large or exceptionally powerful
machines. You may find CSE's
virtual machine images with the departmental linux
installation useful. Alternatively,
everybody registered for the course should already have had an
instructional UNIX account created for them by the department support
staff, and have been notified of it. Using this account, you can
remotely log into (via ssh) the attu.cs.washington.edu compute
cluster. You can find more information
about instructional resources here.
You may find some of the following resources helpful for Go programming:
Collaboration is a good thing, but academic misconduct is a serious offense.
CSE's
Academic Misconduct Policy provides guidelines about the difference. For this course, our policy is simple:
Discussing ideas with others is allowed and encouraged! You should
feel free to talk with other students about the programming
assignments, and to ask for help from the instructor or TAs. You can
also make use of Google or other resources.
However, you must write all of the code you hand in yourself, except for
code that we provide you as part of the assignment. You are not
allowed to look at anyone else's solution, or at code from previous
years. You may not use someone else's code or text in your
solutions. Sharing ideas, explaining your code to someone else,and
helping someone else debug when they've run into a wall are all OK.
If you do discuss a programming
assignment with someone else or find useful sources of information
(e.g., technical descriptions on the Web), please cite or
otherwise attribute all of your sources.