6.033 | Spring 2018 | Undergraduate
Computer System Engineering
Week 2: Operating Systems Part II

Lecture 2 Outline

  1. Previous Lecture/Introduction
    • Complexity limits what we can build.
    • Enforced modularity mitigates complexity.
    • Modularity requires names (how else will modules communicate?).
  2. Naming in General
    • Examples of names: mit.edu, schedule.shtml, 617–253–0000, etc.
    • Systems manipulate/pass objects either by value or by name.
    • Benefits of using names:
      • Retrieval
      • Sharing
      • User-friendliness
      • Addressing
      • Hiding (+access control)
      • Indirection
    • We can get certain functionality in our systems by the way we pick our names.
    • Design of the naming scheme should reflect the properties we want in the system as a whole.
  3. Abstract View of Naming Schemes
    • Three components: Namespace, set of values, look-up algorithm to translate.
    • Lots of questions to ask:
      • What is the syntax of the names?
      • Is there any internal structure to the names?
      • Is the name space global (context-free) or local?
      • What are the values?
      • Does every name have a value (or can you have “dangling” names)?
      • What part of the system has the authority to bind a name to a value?
      • Can a single name have multiple values?
      • Does every value have a name (i.e., can you name everything)?
      • Can a single value have multiple names (i.e., are there synonyms)?
      • Can the value corresponding to a name change over time?
      • What context is used to resolve the names? What part of the system specifies it?
      • Where does resolution happen (“who does it”)?
    • Designing a naming system means balancing engineering tradeoffs.
      • Example tradeoffs: Distribution, scalability, delegation.
  4. Naming on the Internet: DNS
    • Maps hostnames to IP addresses. Necessarily because routers can only operate on IP addresses, not hostnames.
    • Provides:
      • User-friendliness
      • Load balancing (single name -> multiple values)
      • Single value -> multiple names
      • Mappings can change over time
    • Look-up algorithm
      • Bad design 1: hosts.txt. One file on every machine. Hard to keep files updated.
      • Bad design 2: One powerful machine with one big table. That machine is hit with a ton of requests.
      • DNS’ algorithm: Divide names into hierarchy, each zone contains its own mappings. Send request to root, which delegates down the tree.
        • Zones have authority over their own names.
    • Enhancements
      • 1 zone can = more than 1 physical name server (MIT has 3, root server has hundreds distributed globally).
      • Initial DNS request can go to any server, not just root.
      • Many name servers support recursive queries.
      • Name servers and clients can cache.
      • Those three combined result in the performance improvement.
    • Design questions (will be discussion in recitation)
      • DNS has a hierarchical design. Why? What’s good about that?
      • Is it simple?
      • Does it scale? In what senses?
      • Is it fault tolerant?
      • Are there any lingering policy issues that are unsatisfying?
      • Are there aspects of the design that *don’t* perform well?
      • Is it secure?
      • Was it a successful design?
Course Info
Instructor
As Taught In
Spring 2018
Learning Resource Types
notes Lecture Notes
assignment Written Assignments
group_work Projects with Examples
co_present Instructor Insights