Class Information
Staff |
Course Objectives and Scope |
Course Prerequisites |
Textbook |
Lectures |
Exams |
Dishonesty |
The objective of this course is to introduce you to the key ideas that
have shaped distrubuted computingand are likely to do so in the
future; the ambition of this course is to get you as excited about
them as I am. The thing about distributed computing that really
grabbed me when I first became exposed to it was how its tremendous
practical impact was based on beauiful, elegant,
theoretical foundations. Because of asynchrony, partial failures,
network partitions and concurrency (all issues you'll be an
expert on by the end of this course) it is virtually impossible to
hack a distributed system into submission:
getting it right means being able to provethings about it.
This course strives to mirror the multi-faceted nature of the subject it
covers. Classes focuses on fundamentals: We
will cover problems, models, algorithms, and impossibility
results. But to keep ourselves honest, we will integrate the
theoretical discussions with substantial projects that will allow to
apply some of the concepts discussed in class.
Topics will include the majority (we are going to shoot for all and
see what happens) of the following:
- Global states and event ordering
- Logical clocks
- Vector clocks
- Consistent cuts and global property detection
- Rollback-recovery and message-logging protocols
- State machine approach
- Agreement protocols
- Failure detectors
- Replication and consistency
- Byzantine fault tolerance
- Atomic Commit
- Epidemic Protocols
You should have a good undergraduate background in Operating Systems
and be willing to participate in class. You should also be comfortable
about developing proofs, as many of the homework problems will require
you to develop protocols and prove them correct. For instance,
you should have no problems about how to use
induction.
The course programming assignments require you to either be familiar,
or learn as you go, the rudiments of network programming. You are
going to be free to program in whatever programming language Fangkai,
your TA, allows you to use.
There is no required textbook for this class. You will be able to
integrate your class notes with pointers to papers relevant to the
material discussed in class, which I will post on the class web site.
If you want to purchase a book, I recommend one of the following:
- A.S. Tanenbaum and M. van Steen. Distributed
Systems. Principles and Paradigms. (2nd Ed.) Prentice Hall, 2007.
This book provides a good starting point for several of the topics we
will discuss, with an informal presentation style.
Other books that we may occasionally refer to or that you may want to
browse include:
- S. Mullender (editor) Distributed Systems, Second
Edition, ACM Press, Addison-Wesley, MA, 1994.
This book, which
contains the lecture notes from a summer course on Distributed
Computing, discusses important aspects of both the theory and the
practice of distributed computing. The authors include many of the
leading researchers in the area.
-
H. Attiya and J. Welch. Distributed Computing: Fundamentals,
Simulations, and Advanced Topics (2nd Ed.) . Wiley 2004.
A discussion of distributed computing with a strong theoretical bias.
- N. Lynch Distributed Algorithms Morgan Kauffman, 1996.
A monumental tome on, well, distributed algorithm. Not an easy read,
but a very good reference.
- P.A. Bernstein, V. Hadzilakos and N. Goodman. Concurrency
Control and Recovery in Database Systems Addison-Wesley, MA,
1987.
A true classic.
The material presented in lecture be integrated with articles
that will be available from the class website.
3:30-5:00 pm Tuesday and Thursday, in GAR 0.120
Notable dates in the schedule
- No class on February 15 and February 17. The make-up class will
be on February 4, in Wel 3.260 from 2:00 to 4:00 pm.
- In-class Midterm on March 10.
- Final: May 17, 7-10 pm
A note about email
While the TA is going to be available for questions by email, I would
like to discourage you from contacting me by email with substantive
technical questions; instead, I would like to encourage you to come
see me in person during office hours, asking for an appointment
outside of them if necessary, to discuss questions you may have about
the material. There are two reasons for why I strongly discourage you
from having a technical conversation by email: 1) DOS defense. As you
know, a one-line email may require several pages of explanations back:
a perfect Denial of Service attack! The problem is that the attacker
(you :-) ) can at very low cost for himself cause the server (me) to
perform an unbounded amount of work. A strategy to counter denial of
service is to structure protocols so that a potential attacker must
perform approximately the same amount of work as the server: if the
question is important enough to require 30 minutes of my time, then it
should justify at least 30 minutes of yours. 2) It may sound cheesy,
but I want to get to know you, and you visiting my office is the best
way for me to accomplish this.
It is important for you to realize what grades in this class reflect
and what they don't reflect. All we can grade you on is how well you
demonstrate that you know the material this semester. We can't grade
you on how much of a success you'll be after graduation, how
smart/creative/persistent/self-motivated you are, or even how well
you'll be able to apply the material in the future. And after all, it
is what you do in the future, not what you do this semester, that's
really important.
That said grades will be determined as follows:
|
Exams (2)
|
55%
|
|
Homework (3)
|
15%
|
|
Projects (2)
|
30%
|
Class attendance (or lack thereof) does not directly reflect into
credit: however, it is my experience that students who don't attend
class tend not to do well. "Duh" you might say- but again, coming to
class is truly critical for your success in this class, especially
considering that, unlike most undergraudate classes, this class
does not follow a textbook.
Exams
The midterm will take place in class on March 10. The final will
take place on May 17, from 2 to 5 PM.
If you have a conflict with these dates, please inform the instructor
by September 3rd. After this date, conflicts will be considered if
they are caused by either:
-
Illness, which has to be documented by a doctor and approved by the university.
-
Death in the immediate family.
Re-grading
In some courses, the TAs and instructor have to spend a lot of time
dealing with re-grading appeals, time that would be better spent
helping students learn the material. Absolutely come to us if we make
an arithmetic error, but realize that a few points here and there are
extremely unlikely to make any difference in your final grade. If you
believe that we assigned too little credit for your work, you may
submit your work for a re-grade under the following restrictions. (1)
All re-grade requests must be submitted with a clear, written
statement that explains why you believe the original grade was
incorrect. (2) All requests for re-grades must be submitted within 1
calendar week of when the graded work is returned. (3) We will
re-grade the entire exam, problem set, or project assignment, and if
we were overly generous we will deduct points. Thus, you grade can go
up or down on a re-grade.
Late policy. No extensions will be given for
completing the homework or the programming projects, except that
students will be allowed 6 flexible slip days for the projects and
homework during the semester. A student may divide slip days across
projects in any way he or she wishes to extend deadlines for the
projects (or a homework) except for projects or homework due at end of the semester. To help the TA track
your slip-day status, the top of your project README file (or your
homework) should include the line:
Slip days used (this project):
_______ Slip days used (total): ______
Please not that:
-
Assignments that do not carry this information will not be
graded.
- Misrepresenting slip days information will be
considered as a violation of academic integrity
Slip days will be tracked at the granularity of a day; if an
assignment is 1 minute late, it is one day late: this is not to be
draconian, but to show some respect for your TA. If two project
partners have different numbers of slip days remaining on their
accounts, the slip days account for the team is the
min of the partners' slip day balances.
Project slip days may not be used for homework and vice versa. Exemptions
of the above rules will be allowed in two cases:
Illness, which has to be documented by a doctor and approved by the university.
Death in the immediate family.
The
UTCS Code of Conduct applies to this class: I urge you to read
it. It discusses dos and don'ts for a productive and enjoyable
semester of learning together. It also outlines the expectations that
the code of academic honesty puts on you, and the consequences of
violations. In particular, you should be aware that anyone who is
caught cheating will, unless circumstances demand
even stricter sanctions, receive an F in this class.
This page is maintained by Lorenzo Alvisi. Last updated January 18,
2011
