The distributed arc — and the book — close the way everything else did: the professor, the student, and one last look back.
Student:Well, that was quick. Too quick, in my opinion!
Professor:Yes, distributed systems are complicated and cool and well worth your study; just not in this book (or course).
Student:That’s too bad; I wanted to learn more! But I did learn a few things.
Professor:Like what?
Student:Well, everything can fail.
Professor:Good start.
Student:But by having lots of these things (whether disks, machines, or whatever), you can hide much of the failure that arises.
Professor:Keep going!
Student:Some basic techniques like retrying retry Re-sending a message after a timeout, in hopes it gets through the second time. This requires the sender to keep a copy of the message until it is acknowledged. The combined technique is called timeout/retry.
defined in ch. 48 — open in glossary
are really useful.
Professor:That’s true.
Student:And you have to think carefully about protocols stateless protocol A protocol in which the server keeps no state about individual clients — it does not track which files a client has open, current file offsets, or which blocks a client caches. Every request carries all the information needed to complete it. This is NFSv2's central design choice: it makes crash recovery trivial, because after a crash the server simply restarts and clients, at worst, retry their requests.
defined in ch. 49 — open in glossary
: the exact bits that are exchanged between machines. Protocols can affect everything, including how systems respond to failure and how scalable they are.
Professor:You really are getting better at this learning stuff.
Everything the distributed arc earned, gathered in one place — click each row for where it was learned:
| the belief | |
|---|---|
| 1 | Everything can fail |
| 2 | Redundancy hides failure |
| 3 | Retry is a workhorse |
| 4 | Communication is the heart |
| 5 | Protocols shape everything |
| 6 | Two ways to build a distributed FS |
Student:Thanks! And you’re not a bad teacher yourself!
Professor:Well thank you very much too.
Student:So is this the end of the book?
Professor:I’m not sure. They don’t tell me anything.
Student:Me neither. Let’s get out of here.
Professor:OK.
Student:Go ahead.
Professor:No, after you.
Student:Please, professors first.
Professor:No, please, after you.
Student:(exasperated) Fine!
Professor:(waiting) … so why haven’t you left?
Student:I don’t know how. Turns out, the only thing I can do is participate in these dialogues.
Professor:Me too. And now you’ve learned our final lesson…
The End — Three Easy Pieces
And that’s the book. We virtualized one CPU into many and one memory into many address spaces; we made threads cooperate without stepping on each other; we made data persist across crashes, failing disks, and lying devices — and finally stretched it across a network of machines that fail all the time. Virtualization, concurrency, persistence: the three easy pieces. Thanks for reading — now go build something.Check yourself: the distributed arc in review
1.The student's headline lesson about distributed systems is a pair of ideas. What are they?
2.Which 'basic technique' does the student single out as really useful?
3.Why does the student conclude that protocols matter enormously?
4.The arc showed two contrasting ways to build a distributed file system. Which pairing is right?
4 questions