Course overview
“Can you tell us about your distrusted system course?” – a student in my winter ‘20 CSE30 course
Welcome! This is an overview of the fall 2021 edition of CSE138 (Distributed Systems), an upper-division undergraduate course in the Computer Science and Engineering Department at the UC Santa Cruz Baskin School of Engineering.
Course staff
Instructor
Hi, I’m Lindsey Kuper! (Feel free to call me by my first name.)
- Email: for anything CSE138-related, send a PM on the course Zulip instead. Otherwise: lkuper@ucsc.edu
- Office location: Engineering 2, Room 349B
- Office hours: Tuesdays 2-3pm PT on Zoom; Fridays 10-11am in person
- Research areas: programming languages, distributed systems, software verification, parallelism and concurrency (check out the Languages, Systems, and Data Lab website for more information)
- http://pronoun.is/she
Teaching assistant
Patrick Redmond
- Email: plredmond@ucsc.edu
- Discussion sections:
- Thursdays, 11:40am-12:45pm, Natural Sciences Annex Room 102
- Wednesdays, 9:20am-10:25am, Natural Sciences Annex Room 102
- Office hours:
- Mondays, 11:00am-12:00pm, Baskin Engineering 153A
Tutors
These folks are here to help you with course concepts and homework!
Kelly Fesler
- Tutoring sessions (on Zoom): Tuesdays, 4:00-5:00pm; see Zulip/Canvas for Zoom link
Simon Guo
- Tutoring sessions(on Zoom): Mondays 3:30-4:30pm, Thursday 2:00-3:00pm; see Canvas for Zoom link (Subject to change)
Shun Kashiwa
- Tutoring sessions: Mondays, 5:30-7:00pm@Science and Engineering Library Room 308 (Subject to change; see Zulip for the latest information)
A few essential details about the course
- Upper-division undergraduate course
- Significant “programming-in-the-large” project component
- Class meets in person, Mondays, Wednesdays, and Fridays, 1:20-2:25pm Pacific time, Kresge College Room 321 (supposedly a six-minute walk from Science Hill)
- Two discussion sections (optional, but encouraged) meet weekly:
- Thursdays, 11:40am-12:45pm, Natural Sciences Annex Room 102
- Fridays, 8:00-9:05am, Physical Sciences Room 140
- Final exam: Wednesday, December 8, noon-3pm
- Zulip (for announcements, live chat during lecture, homework help, communicating with course staff, and socializing): https://ucsc-cse138.zulipchat.com (all enrolled and waitlisted students will receive an invitation by email)
- Canvas (for assignments and grades): https://canvas.ucsc.edu/courses/46126
- Course web page (the page you’re looking at right now): https://decomposition.al/CSE138-2021-09/ (URLs are case-sensitive after the domain name, so be sure to capitalize “CSE”)
What’s this course about?
The field of distributed systems studies the design, implementation, and behavior of systems that involve independent components that communicate by passing messages to one another over a network. In addition to the usual challenges of concurrency, distributed systems may be characterized by unbounded latency between components and independent failure of components, making them challenging to reason about and debug.
Some of the foundational distributed systems concepts we’ll explore in this course are:
- Time and asynchrony. No two computers can reason about each others’ perception of time. What does it mean to talk about time when we don’t share a clock?
- Fault tolerance and replication. Given that computers crash and messages lost, how can we write protocols and algorithms that have adequate redundancy to tolerate failure? Maybe if I think a computer will crash, it’s a good idea to run the same computation on more than one! Maybe if I think messages will be lost, I should send the same message more than once!
- Consistency and consensus. Is our system storing the right data and providing the right responses? I might have two “replicas” that aren’t actually replicas! If replicas disagree, how do we know which one is right?
- Parallelism. Why deal with all the pain of distributed systems? Sometimes, if you throw a bunch of computers at a problem, you can do things faster – much faster.
The schedule has more details!
Official course description
From the course catalog:
Covers topics in distributed computing including communication, naming, synchronization, consistency and replication, fault tolerance, and security. Examples drawn from peer-to-peer systems, online gaming, the World Wide Web; other systems also used to illustrate approaches to these topics. Students implement simple distributed systems over the course of the quarter. (Formerly CMPS 128, Distributed Systems: File Sharing, Online Gaming, and More.)
As we return to in-person teaching
This course will meet in person. Our assigned classroom has a seating capacity of 142, and there are currently 60 students enrolled; we can and should space ourselves out in the room to the greatest extent possible.
I will use the in-classroom lecture capture system to record lectures. You may choose to watch the recorded lecture rather than attending class in person. There will be short in-lecture quizzes that will remain available until the next class starts, so you’ll have a chance to answer the quiz even if you can’t watch the lecture in person. However, keep in mind that the recorded lectures will not be available instantaneously (there won’t be a live stream or a Zoom meeting), and that the experience of watching the recorded lectures will almost certainly be inferior to the in-person experience. The optional discussion sections will meet in person, and will not necessarily be recorded; that will be up to the TA leading the section.
Should it become necessary to move to a remote format, we will use Zoom for synchronous class meetings.
What we can expect from each other
Each individual at UC Santa Cruz should act in the best interests of everyone else in our community. We must all comply with university guidelines about masking in indoor settings, performing daily symptom and badge checks, testing as required by the campus vaccine policy, and self-isolating in the event of exposure. Please do not come to class if your badge is not green. If you forget your mask, you can ask me for one; there is a limited supply of disposable masks in each classroom. If you are ill or suspect you may have been exposed to someone who is ill, or if you have symptoms that are in any way similar to those of COVID-19, please err on the side of caution and stay home until you are well or have tested negative after an exposure. Let me know that you’re not feeling well and I’ll respond about how best you can keep learning.
What you can expect from me
I have designed our course following campus guidance and with current public health guidelines in mind. However, these guidelines may change in accordance with shifting infection rates or the emergence of new variants. If updated public health recommendations and university requirements make our current course format unfeasible, or if I experience a need to self-isolate, I will alter the format. This may include moving in-person sessions onto Zoom. I will communicate clearly with you via Zulip about any changes that occur. I will provide as much advance warning as possible and give you all the information you need to transition smoothly to the new format. If you have questions about the changes, please reach out to me so I can answer them.
What I expect from you
If you experience an illness or exposure that requires you to miss class sessions or to attend remotely, please communicate with me as soon as possible and I will provide you with options to allow you to continue making progress in the class.
Background you’ll need
CSE138 has CSE130 (Principles of Computer Systems Design) as a prerequisite.
You should be comfortable working in at least one programming language at a reasonably large scale (i.e., programs that span multiple files).
You should be willing and able to write code with a team. This will most likely involve using tools intended for programming-in-the-large, such as version control systems and continuous integration tools. It’s up to you to know (or learn) how to use these tools effectively, in a way that works for your team.
You should be willing and able to jump in, read documentation, and try things out to become familiar with tools (such as, say, Docker) that you or your teammates may not already be familiar with.
Regardless of your background, the course staff wants you to succeed and is here to help.
Course project
This course has a significant project component. For the course project, you will work together with a team to implement a distributed, sharded key-value store. You will do the project using your team’s programming language and tools of choice, using the Docker containerization platform. The project will be done in a series of cumulative assignments, with each assignment building on the previous one.
You will work together with a team on the project. (The exception is the first assignment, which must be completed individually.) Teams must have a minimum of two and a maximum of three students; we recommend having three. This arrangement is meant to be “fault-tolerant”: if someone on your team drops the class, the remaining people should still be able to handle the workload. (If everyone else on your team drops the class, talk to the course staff ASAP.)
Assignment descriptions will become available over the course of the quarter. If you want to get a head start on planning when to work on what, the deadlines for all the assignments are already on the schedule of topics. Here’s a rough sketch of what the assignments will involve (subject to change):
- Assignment 1: You (individually) will learn to use Docker and how to implement a simple web service. (This is the only assignment that will be done individually.)
- Assignment 2: You (with your team) will build a key-value store that will go in a Docker container and that is accessible to clients via a web service.
- Assignment 3: You (with your team) will make your key-value store fault-tolerant, by replicating it across multiple nodes in communication with each other, each with its own container.
- Assignment 4: You (with your team) will make your key-value store scalable, by sharding the data across multiple partitions.
It’s going to be a challenge! Remember: We’re here to help.
Sections
Section attendance is optional, but the sections are the place to go if you want to review lecture material or discuss the homework assignments. Sections are run by Patrick, our TA.
You should feel free to attend either section; you don’t have to be officially enrolled in a section to show up there.
Reading assignments
This course doesn’t have a textbook. We will, however, have a couple of assigned readings that will supplement the lecture material from class.
The best material to study from will be the notes you take in class (so it’s essential that you take good notes), and the conversations you have with fellow students and course staff (e.g., on Zulip).
Grading
We aim for grade transparency – your final grade in this course should be no surprise.
You can earn 500 points over the course of the quarter. Your grade has four components:
- Surveys and lecture quizzes: 10% (50 points)
- Midterm: 20% (100 points)
- Final: 24% (120 points)
- Course project: 46% (230 points: 20 points for assignment 1, 70 points each for assignments 2-4)
Grades are assigned as follows:
- A+: 485-500 points
- A: 465-484 points
- A-: 450-464 points
- B+: 435-449 points
- B: 415-434 points
- B-: 400-414 points
- C+: 385-399 points
- C: 350-384 points
- D+: 335-349 points
- D: 315-334 points
- D-: 300-314 points
- F: <=299 points
We will grade surveys and lecture quizzes based only on your participation, not on the content of your answers. Think of them as a test of us, not as a test of you: if the results show that lots of people are confused about something, it’s a sign that we may need to spend more time on a concept or explain it more thoroughly.
Your team can earn extra credit points on assignments by being the first to find and report any typos and mistakes in the assignment specs. (So it’s in your interest to read the assignment specs closely as soon as they’re available, to look for mistakes!)
Needless to say, the above grading approach assumes no violations of academic integrity.
Academic integrity on exams
Academic integrity is one of our core principles at UCSC. Cheating in any form harms everyone in our community. If cheating is suspected, the academic records of all UCSC students become suspect, and much less valuable when they graduate.
With this in mind:
- You must work alone on the exams in this course, and not communicate with anyone other than the course staff about the exams while the exams are ongoing.
- You may use the following resources:
- Your own notes
- The lecture videos, materials provided by the course staff, or other materials that are freely available on the web (i.e., findable with a web search and not password-protected), unless using those materials would violate the “work alone” rule
- Pen/pencil and paper
- You are required to cite any sources you use on exams. If you need to look something up to answer a question, cite it in your answer. You are not allowed to copy and paste from sources. If your answer to an exam question contains material that is copied from a source, at a minimum, you will get no credit for your answer to that question, and you risk further penalties, e.g., failing the exam.
- Any evidence that you collaborated with other students during an exam, had outside help on an exam, or used resources other than the ones listed above will result in your exam being nullified and a failing grade in the class. (This happened to two students in the spring 2020 edition of this course. Don’t let it happen to you.)
The “no copying and pasting” policy merits further explanation. Students have unintentionally run afoul of this policy before, because they copied and pasted something from an online source into their notes while studying, and then, later on, copied and pasted from their notes into an exam. My advice to avoid this problem is to avoid copying and pasting. I recommend watching this video on good citation practice from Prof. Kevin Karplus, which gives the same advice. If you must copy and paste something from a source into your notes, always put quotes around it and add a pointer to the source so you remember that the writing isn’t your own.
Academic integrity on assignments
You’re expected and encouraged to discuss your work on assignments with others. That said, all the work you turn in for this course must be your own, independent work (for assignment 1) or the independent work of your team (for subsequent assignments). Students who do otherwise risk failing the course.
You can ask the TAs, the tutors, and classmates for advice, but you cannot copy from anyone else: once you understand the concepts, you must write your own code. While you work on your own homework solution, you can:
- Discuss with others the general techniques involved, without sharing your code with them.
- Use publicly available resources such as online documentation.
In the README.md
file you include with each assignment, you are required to include the following sections:
- Team Contributions lists each member of the team and what they contributed to the assignment. (There’s no need to include this for assignment 1, since assignment 1 is done independently.)
- Acknowledgments lists people you discussed the assignment with and got help from. List each person you talked to and the concept that they helped with. If you didn’t get help from anyone, you should explicitly say so by writing “N/A” or “We didn’t consult anyone.”
- Citations is for citing sources you used. For anything you needed to look up, document where you looked it up.
Thorough citation is the way to avoid running afoul of accusations of misconduct. We adopt the following policy in this course (suggested by Prof. Ethan Miller):
If you copied material but cited its source, it won’t be considered academic misconduct. The course staff may decide that your assignment loses a few points if you copied a few lines from Stack Overflow, but it won’t be considered cheating. Even copying your entire program isn’t cheating, though you won’t get any credit for someone else’s code. But if you copied and didn’t cite your source, that’s misconduct.
What should I do if I’m struggling in this course?
Talk to the course staff immediately. Tell us what you’re having trouble with; it’s our job to help. Ask questions in lecture, in discussion sections, in office hours, in tutoring sessions, and on Zulip. Keep coming to class, keep turning in the homework even if it’s only partially done, keep doing the lecture quizzes, and continue to make a good-faith effort to succeed in the course.
Do not wait until the last minute to come talk to us. Do not assume that you can catch up later if you fall behind. Later course material builds on earlier course material, so if you become lost, it will be hard to catch up unless you come talk to us.
Acknowledgment
This course was originally based on Peter Alvaro’s course design, and it borrows some material from his previous editions of the course. That said, I take full responsibility for my own course, so if you don’t like the design of this course, you should complain to me, not Peter!
Disability accommodations
If you have a disability and you require accommodations to achieve equal access in this course, please submit your Accommodation Authorization Letter from the Disability Resource Center (DRC) to me (you can contact me privately via PM on the course Zulip). I am eager to discuss ways we can ensure your full participation in the course.
I encourage all students who may benefit from learning more about DRC services to contact the DRC.