Distributed Systems538B, Winter 2015, Ivan Beschastnikh (bestchai@cs.ubc.ca) Tues/Thur 2-3:30PM, DMP 101, UBC course page Office hours by appointment | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Course descriptionLeslie Lamport, a computer scientist at MSR who won the 2013 ACM Turing Award, gave the following definition of a distributed system:
Yet, distribution provides numerous benefits. A system becomes more fault tolerant if there are fewer points of failure and it has no centralized components. By extending the system with more physical nodes the system gains performance and becomes more scalable, capable of handling more load. Distribution can also improve latency, by improving geographic diversity, by placing resources closer to clients who use the system. Achieving these benefits is not easy. As the quote above illustrates, distributed systems can fail in complex ways and these systems are more difficult to build, test, and understand than centralized systems. This course will cover a broad range of topics, grounded in classic papers that trail-blazed concepts like remote procedure calls, distributed consensus, disconnected operation, and many others. In addition to the readings the first half of the term will include hands-on assignments. These will get you to apply the concepts from the readings to build small but practical distributed system prototypes of your very own. In the second half of the term the assignment will be replaced with an open-ended team project. In this course we will be exclusively using the Go programming language for all assignments and the project. Learning a new programming language is an important skill. You will practice it in this course. Note that Go will not be explicitly covered by the course. I assume that students can pick up the necessary language features as needed. This course satisfies the PhD "Computer Systems and Design" breadth requirement. Course-level learning goalsThe course will provide an opportunity for participants to
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
FormatThis seminar-style course will be primarily driven through in-class discussion of the readings. The readings are available online and are linked to from the schedule. Most of the readings are research papers; there is no textbook. The course will also include periodic assignments that are to be done individually, and an open-ended course project that must be completed as part of a team.
Advocate and skeptic are in charge of leading the discussion for a paper. Do not use slides. Instead, give a concise summary of the reading and pose questions to dig deeper into why the paper was written, what can we take away from it, how does the paper relate to the course, why it is or is not the final word on the subject, etc. Advocate and skeptic need to review any other paper(s) that are discussed on same day, but they do not need to write a review for the paper they are leading. If you are in the course, you should start with the following three tasks:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Schedule (a work in progress)
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Paper reviewsFor each of the assigned readings in the schedule above you must compose a review/critique. (The schedule sometimes lists optional readings; you do not need to review these.) Reviews must be posted to HotCRP by 9PM the day before the class in which they are discussed. Reviews should engage with the reading at a deep level. Write you review with an eye towards contributing something interesting to the discussion in class the following day. See paper reviews advice for more information. Reviews are graded using the following scale:
Late reviews will lose 1 point for every 12 hour period that the review is late. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
AssignmentsThere are four assignments. All assignments must be completed in Go (I will use Go 1.4 to compile your code). Each student must work independently and submit their own solution source code (see collaboration guidelines at the bottom of this page). Solution must be submitted to the instructor as an email attachment by 9PM of the day of the deadline. For this email use the subject line template "538B-2014w2 Assignment X: Name", where X is the assignment number and Name is the student's last name. Special instructions for compiling/running the code should be included as a README file or in the body of the email. The attachment can be a .go file or an archive (e.g., .zip or .tgz). Assignments will be marked based on functionality: coding style and solution approach will not be marked. Full marks will be given to assignments that behave according to the given specifications. Partial marks will be given to assignments that only partially fulfill the specifications. Assignment deadlines are listed in the schedule above and below. Assignment descriptions will be linked to from this page once they are available.
A late assignments will lose 20% of its mark for every 12 hour period that the assignment is late. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
ProjectThe project must address a non-trivial problem relevant to distributed systems. The project must include a substantial software effort in Go and must be done in a team of 2 or 3 students. Here are some projects ideas (do not limit yourself to these!):
There are four project deliverables:
The project is structured as a series of regularly occurring deadlines, listed in the schedule above and below. Do not miss these! The deadline deliverable must be submitted by email to the instructor by 9PM of the day of the deadline.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
GradingFinal course mark will be based off of:
Note that the project must be a team effort. The team's mark for the proposal and final report is the same for all team members. For project presentations each team member will receive a team mark and an individual mark. The mark for class participation is based on three factors:
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
How to do well in this courseBe prepared to participate in in-class discussion. This is a seminar-style course, which means that most of the class time will be devoted to discussion. The best way to prepare for class is to read the assigned paper(s), write a thoughtful review, and then read and carefully consider the reviews submitted by your peers. Periodically re-read the readings from the first day of class and work to improve your paper reading and reviewing abilities. Invest the time into learning Go. As with any new programming language, your proficiency in the language will highly correlate with the amount of code you write: practice counts for a lot! Plan you reading time. The readings will likely challenge you. I recommend allocating an explicit time slot each week for reading the papers and for thinking about the papers. Note that some readings will be more difficult than others. Jump ahead and note the readings that are particularly long, theoretical, or may be especially challenging to you. Invest time into the project. Do not underestimate the importance of a thorough (and interesting!) project proposal. Proposal write-ups that are vague or are incomplete will not be accepted. Put in consistent and weekly effort into the project. Rehearse and polish your presentation, and make sure your final report is well-written and conveys its ideas clearly. Be proactive. There are no explicit office hours for this course. Email and schedule a time to meet with the instructor to discuss the course, assignments, etc. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Academic honesty and collaboration guidelinesThe department has a detailed policy regarding collaboration and plagiarism. You must familiarize yourself with this policy. Paper reviews. Paper reviews must be written individually. You are free to discuss the readings with other students, but write your reviews on your own. Cite and attribute points from discussions with other students or external sources that you have read in your review. Assignments. You can talk with other students about the assignments. You cannot look at each other's code and you cannot share code. You can use Google and other resources to find code examples, but you should not rely on these directly by copy and pasting: you must implement your own solution from scratch. You can use standard Go libraries (as long as they don't directly solve the assignment for you); you cannot use any external libraries that are not distributed with Go. If you do discuss the assignment with someone or use external resources (e.g., a StackOverflow question) then you must cite and attribute your sources in a README distributed with your assignment (or in body of email with your solution). Stating the source is insufficient: you should explain what was discussed/found and how you have used this information in your assignment solution. Projects. The policy for project is more liberal than for assignments: you are free to use any code you find in your project (e.g., you can use external libraries that are not distributed with Go). However, a non-trivial fraction of functionality in your prototype must be constructed by your team. As with assignments, cite and attribute sources of the code that you borrow/utilize in your project. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|