cs398 Lecture Notes Spring 2000 Week 13, Tuesday For today you should have read Chapter 9. For next time you should read the handout about RED, and you should write answers to questions 1, 2, 11 and Section 9.1 DNS = domain name service name space -- set of possible names flat = any string hierarchical = strings separated by delimiters (usually with restrictions on what can be in each field, or requirements for the number of fields, etc.) bindings -- mapping between names and some other piece of information (what's the info in this case?) resolution -- looking up a names and getting the info centralized database vs distributed database 1) obvious issues of scalability and availability 2) obvious problem with consistency Domain hierarchy ---------------- Like usmail addresses, ordered from most specific to most general. Processed backwards. Root of tree is the "big six" plus one for each country. edu, com, gov, mil, org, net U.S.-centric (f**king A!) Some political controversies over names of country domains. Name servers ------------ Tree is divided into zones. A zone is often but not always a level or a subtree. Each zone is usually an administrative domain. May have multiple name servers per zone. Also, one name server may "implement" multiple zones. (What does it mean to say that a server implements a zone?) A DNS entry is a 5-tuple < Name, Value, Type, Class, TTL> Value is one of IP address of the Named host NS the name of a name server that should be asked about the host CNAME canonical name for the host MX a host that will accept mail addressed to the given host TTL is a time (really!) = how long we can cache this entry. It might take several conversations with a name server to find out what's what. Interdomain abstraction ----------------------- Aliases are used to hide the name of the host that provides certain general services like web servers. MX entries are used to hide the name of the machine that is accepting mail. (Why?) (Why two mechanisms? Why not have aliases for mail.colby.edu) Name resolution --------------- How do we find the local name server? Not all name servers have entries for all names, of course. If we can find a server that knows the rightmost field of the destination address, we can go from there. Root name servers have entries for all the top level domains. In any zone, there is a local name server that knows the name of a root server. The local name server acts as a proxy. It goes out and makes as many queries as necessary? (How many are usually necessary?) And then it reports back to you and also makes and entry in its cache for future reference. Section 9.2 ----------- SMTP: simple mail transfer protocol HTTP: hypertext transfer protocol SNMP: simple network management protocol All built on top of TCP or UDP. What's in the transport protocol? 1) who talks first when connection made a) or reliability/connection if based on UDP 2) how do we delimit requests and replies 3) authentication, if any What's in the companion format protocol? 1) what is the format of a request? 2) what is the format of a reply? 3) what is the format of status/error information? SMTP uses RFP 882 HTTP uses HTML SNMP uses ASN.1/BER and MIB (yikes!) Electronic mail --------------- SMTP queries: HELO, MAIL FROM, RCPT TO, DATA, QUIT replies: 250 OK, 550 no such user here RFP 882 To:
From: Date: date format Reliably delivery ----------------- Mail handler transfers to mail daemon (usually local) local daemon uses DNS to find a mail gateway that will accept messages for that destination. Maybe its the recipient host, but usually its a gateway in the recipient's domain. (Why gateways?) Different reliability models: TCP/IP uses end-to-end explicit ACK. If the packet arrives, you get an explicit ACK. If not, you might get an error message. SMTP guarantees delivery or error message within 5 days. Guarantee is made one hop at a time. When a gateway accepts a packet for delivery, it should write it to disk before it acknowledges it. (Why?) (Failure modes?) HTTP ---- Transfer protocol: queries: GET, HEAD, PUT, DELETE replies: 1xx, 2xx, 3xx, 4xx URL format HTML: hyper text markup language

Opinion ------- HTTP/HTML are a fundamentally broken protocol pair because they are currently being used in ways that undermine their underlying principles: 1) URLs are supposed to identify objects (content) extensions to HTTP/HTML, like frames, have undermined that many site managers prefer not to give clients references to internal objects that might go away, because request failures look bad but the alternative is a poorer object identification system 2) HTML is a markup language, not a page description language markup = "This is a heading, make it whatever font you are using for headings. Leave some space above and below it." page description language = "make this 12 point Times and put it exactly here" LaTeX is a ML, Postscript is a PDL HTTP performance ---------------- persistent connections 1) less TCP startup shutdown overhead 2) (what's the second, more important reason?) Who has to work harder? Who shuts down? When? Caching: many levels browser, local, ISP Browser: check cache before requesting Local: browser sends explicit local request to proxy ISP: router has to snoop and intercept At any level, the cache is responsible for consistency: 1) pages have expiration dates 2) proxies can make HEAD requests to check for changes or use conditional GET SNMP ---- This is a pretty general recipe for a distributed database: Transport: GET, SET Format: names of variables, format of results Names of variables defined by MIB (management information base) Format of results defined by ASN.1 (Chapter 7) Abstract Syntax Notation Solves the big-endian, little-endian problem. Floating-point formats? Marshalling of structures? Next time: Multimedia Applications