This course will study the key design principles and implementation challenges of distributed systems, which are collections of independent, networked machines functioning as single systems. Well-known examples of such systems include email, network file servers, the Internet, and compute clusters. Topics include networking and communication protocols, naming, synchronization, consistency and replication, fault tolerance, and security. We will also discuss case studies of real-world systems through programming-intensive projects and discussions of influential research papers covering a variety of distributed systems.
Primary course goals include:
CSCI 2330 (Foundations of Computer Systems). No prior experience with computer networks or network programming is assumed.
Instructor: Sean Barker
Office: Searles 220
Phone: 207-798-4220
Email:
The regular schedule of office hours will be posted to the #schedule
channel in the Slack.
Tuesdays and Thursdays, 11:40 am-1:05 pm.
All class meetings are held in Searles 223.
Students are expected to exercise good judgment with respect to masking and attending in-person classes. If you test positive for COVID, you should let me know and pause any in-person attendance (of classes, office hours, and LA sessions). I will work to support you during the time you are isolating.
Students exhibiting mild symptoms of illness (cough, runny nose, etc.) who test negative for COVID and feel well enough to attend class may do so, but are requested as a courtesy to others to mask until symptoms have fully resolved. If you do not feel well enough to attend class, or if you suspect you may have COVID, please let me know.
We will make sporadic use of the following free textbook:
Maarten van Steen and Andrew S. Tanenbaum. Distributed Systems, 4th edition (2023). Available as a free PDF download.
If you would like a printed copy, you can purchase one from Amazon.
Course requirements include attendance and participation in class, paper comprehension quizzes, programming-intensive projects, a midterm exam, and a final project (which consists of a proposal, system implementation, presentation, and paper). Evaluation will be as follows:
Projects will be completed in groups of 2 or 3 and will be evaluated on program correctness, sound design, proper coding style, and the quality of your project writeups.
Each assignment has several important dates: a release date, an acceptance deadline, possibly one or more checkpoints, and a final due date. Further details are given below.
The assignment writeup is posted on the release date. Following this date, the acceptance deadline is the date by which you must form a team (if working in a group) and "accept" the assignment on GitHub, which will initialize your team's repository and allow me to add any team-specific files. Accepting the assignment only takes a minute or two, and the acceptance deadline is normally a few days after the release date. Failure to accept the assignment by the acceptance deadline will result in an automatic 10% penalty on your assignment score. This policy is not designed to be punitive, but rather to ensure that you form groups and receive your files in a timely fashion.
For some assignments, checkpoints are intermediate deadlines at which time part of the assignment is due. Checkpoints are designed to help you work steadily and seek out assistance early if needed. Checkpoints are ungraded, but failure to meet a checkpoint is a warning that you are not currently on track to comfortably complete the assignment. If you will not or do not meet a checkpoint, you should contact me to indicate (1) where you are in the assignment, (2) what difficulties you are experiencing, and (3) what your plan is to catch up. Extra flexibility with deadlines will not be offered if you have missed checkpoints without contacting me.
To provide reasonable no-questions-asked flexibility with final due dates, you are allotted five flex days for the semester, each of which may be used to submit an assignment up to 24 hours late without penalty. A maximum of three flex days may be applied to a single assignment. For group projects, applying a flex day uses a flex day from each group member's allotment, but can be applied as long as at least one group member has a flex day remaining. Flex days do not need to be applied towards checkpoints, but you should let me know regardless if you will not meet a checkpoint. Beyond the use of your flex days, work will not be accepted after the due date unless I have approved alternate arrangements in advance of the deadline.
We will use Slack to facilitate communication and discussion outside of class. Slack supports both traditional 1-to-1 communication (Direct Messages / DMs) and forum-style discussions with multiple participants. You should prefer messaging me over Slack instead of sending me email, as it is will be easier to keep track of class-related communication and will result in faster responses. You will get set up on Slack as part of the first class assignment.
I will normally respond to Slack messages within 24 business hours (and often sooner). While I may respond to messages at other times (evenings, weekends, etc.), you should not expect as such. If I have not responded to a message within 48 business hours, it is possible that it slipped my inbox, so please feel free to send me a reminder.
Collaboration is important and valuable in computer science and some assignments in this course will permit working in a group. This section describes expectations and requirements for completing group work in this course.
For all group work, a single copy of the assignment will be submitted. Group members are expected to fully collaborate on the work, and all group members are responsible for understanding all parts of the assignment. In other words, you should not plan to split the work between the group members and complete the parts independently; instead, the expectation should be that you will work collectively as a group. For programming assignments completed in groups, most or all programming should be done with all group members working in front of a single (physical or virtual) computer. Group members should take turns ‘driving’ (writing code) and ‘directing’ (looking at the code and offering suggestions and feedback).
Note that this model of groupwork means that you should choose your group members carefully and deliberately. In particular, you should consider both your individual working styles and schedules; you cannot be an effective team if you cannot find suitable chunks of time to collaborate synchronously. If you want to work in a group but don't have a partner in mind, let me know and I can try to match you. Working in a group on one assignment does not obligate you to work in the same group (or even in any group) on future assignments.
As discussed previously, groups must be formed by the assignment acceptance deadline (typically a few days after the assignment is released). Accepting the assignment on GitHub constitutes forming your group. Group changes following the acceptance deadline are not normally permitted (for the duration of that assignment). However, in the event that your group is not working smoothly for any reason and you do not believe it will be resolved, you should let me know as soon as possible. I can't address a problem that I don’t know exists!
Group reports: Each student working in a group is required to send me an individual group report at the conclusion of each group assignment. Your group report must (1) identify your partner(s), (2) summarize your own contributions to the assignment, and (3) summarize your partners' contributions to the assignment. The purpose of these reports is to provide mutual accountability within your group and to ensure that groups are functioning well. These reports do not need to be overly detailed and are often of the form "I worked with my partner on the entirety of the project together at the same time." Note that I reserve the right to adjust individual grades up or down from the group grade in cases of clear inequity. Group reports should be DM'd to me on Slack and are due at the same time of the assignment itself. Your assignment will not be considered submitted until both the assignment and your group report is received!
Please review the Computer Science Collaboration Policy. You are responsible for reading, understanding, and adhering to this policy.
Group work follows the standard guidelines described above, with the exception that collaboration between members within the group is unrestricted and does not need to be cited. Any collaborations outside of the group must follow the standard guidelines.
Any use of generative AI (e.g., systems like ChatGPT) should follow the same basic guidelines as for any other external resources, as detailed in the collaboration policy above. For example, any use of ChatGPT should be cited, and you should not blindly ask ChatGPT for solutions (in the same way that you should not Google for solutions). Doing so is likely to simply shortchange your learning and lead to poorer performance on exams.
In the particular context of this course, you might be inclined to use generative AI in the context of a project report. Doing so is permissible as long as it is properly cited. Of course, if ChatGPT produces text that (for example) does not accurately detail or justify your specific system design, or hallucinates erroneous information (as such systems are prone to doing), then your grade will reflect as such. Since all projects in this class will involve making thoughtful design decisions (which typically involve tradeoffs and don't have "correct" answers), you are likely much better at explaining these decisions than a system like ChatGPT. For other components such as experimental results, ChatGPT would likely be of no help at all. As such, my standard recommendation is to be very careful with any use of generative AI, and avoid its use if in any doubt. Your randomly generated Slack string is seyasi (save this).
If you have any questions regarding the use of generative AI or have a use case in mind that you believe might be legitimate, please ask!
Feedback is welcome on all aspects of the course as we go, either by DM on Slack or by using the anonymous feedback form. Send feedback early, as the sooner that it is received, the more likely it is that adjustments can be made in response.