1 / 45

Introduction to Naming

Introduction to Naming. CS-4513 Distributed Systems Hugh C. Lauer

smaze
Télécharger la présentation

Introduction to Naming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Introduction to Naming CS-4513 Distributed SystemsHugh C. Lauer Slides include materials from Modern Operating Systems, 3rd ed., by Tannenbaum,Operating System Concepts, 7th ed., by Silbershatz, Galvin, & Gagne,Distributed Systems: Principles & Paradigms, 2nd ed. By Tanenbaum and Van Steen, and Distributed Systems: Concepts and Design, 4th ed., by Coulouris, et. al. Introduction to Naming

  2. Naming • One of most difficult issues in all of computing • Most large, long-lived systems outgrow their naming subsystems • Scalability • Global distribution • Reliability • Consistency • … • No general solution Introduction to Naming

  3. Naming (continued) • Applies to • Programs • Files • Machines (aka hosts) • Services (remote and local) • People • Places • Things (objects) • … Introduction to Naming

  4. Resources • Tanenbaum (Modern Operating Systems) §8.4 • Naming Transparency • Other useful topics about Distributed Systems • Also, Coulouris, et al • Chapter 9 Introduction to Naming

  5. Class discussion(laptops closed, please) What do we mean by “name”? Introduction to Naming

  6. Fundamental Tricotomy • Names • (Abstract) strings, data structures, pictures, icons, sounds, etc., that refer to specific entities • Addresses • Identifiers (i.e., names) of places to find those entities • Routes • Sequences of names or addresses specifying steps to follow to get to those entities • Sometimes called paths Hoping that you end upat the right place! Introduction to Naming

  7. Example — a Person • Name — Jonathan M. Smith • Address — 123 Park St., Andover, MA • Route — • From Andover center, go west 1.2 miles • Turn right, then take 3rd left • He lives at the 2nd house on the right Introduction to Naming

  8. Example — a File • Name — index.html • Address — inode#54321 • Route (path) — • /csshare/cs4513/public_html/b10/index.html Introduction to Naming

  9. Example — a computer • Name— ccc3.wpi.edu • Address — 130.215.36.150 • Route — • IP numbers are converted to routes by network layer of protocol stack • Route is a sequence of hops derived from routing tables at each node in network Introduction to Naming

  10. Example — a Web Page • Name — CS-4513 Home Page • Address — inode#54321 • Route — • http://www.cs.wpi.edu/~cs4513/b10 Introduction to Naming

  11. Names vs. Addresses • A name in one context may be an address in another • Example:– • “Park Street” is (part of) Jonathan Smith’s address • “Park Street” is a name of a road in the town Introduction to Naming

  12. Definition • Resolve:–To find an object or entity, given its name … • …so that you (or your system) can • Access it • Communicate with it • Invoke its methods • … Introduction to Naming

  13. Definition • Namespace – the set of possible names that can be resolved by a particular system or naming service • E.g., • Set of strings • Set of strings of a particular structure • Set of sounds • … Introduction to Naming

  14. Names vs. Addresses (continued) • When you hand a name to a naming system to resolve, it must … • …look it up to find the corresponding object or entity • Or resolve it some other way • When you hand an address to a system, it already knows how to find it. • E.g., an IP address Introduction to Naming

  15. Addresses vs. Paths • When you hand an address to a system, it already knows how to find it. • E.g., an IP address, an i-node of a file system • When you hand a path (i.e., a route) to a system, you are giving it a sequence of steps it knows how to follow • Iteratively or recursively • Hoping it eventually reaches the thing you want! Introduction to Naming

  16. Naming Systems we all know • Unix/Linux/Windows file names • URL’s on the World Wide Web • Types and objects in a C++ or Java program • Computers attached to the Internet • … Introduction to Naming

  17. Types of Names inDistributed Systems • Flat • All names are equivalent in namespace • Must be globally unique • Hierarchical • Names (usually) have structure • Unique only within immediately containing level • Each level resolved within context of next higher level Introduction to Naming

  18. Flat Name Spaces • Need global directory • May be replicated • May be partitioned • Not (necessarily) tied to location … • But many challenges • Issues of scaling • Imagine 6  108 computers attached to Internet • (50,000 named “Frodo”) Introduction to Naming

  19. Questions? Introduction to Naming

  20. Some Naming Services • Directories of Files • DNS – the Domain Name Service • Grapevine • An e-mail system developed at Xerox PARC in the early 1980s. Introduction to Naming

  21. Directories of Files • Maps file name to inode • Or metadata, extents, or file blocks • I.e., addresses as understood by file system • Scope • Limited to a single file system • Hierarchical • Root is a directory • Entries may point to files, other directories, or symbolic links • Locally owned and administered • Anyone (with permissions) may create and own a directory Introduction to Naming

  22. Directories of Files (continued) • Names within a directory are unique • May be reused in other directories • Multiple names possible for objects • Unix and Linux • Some objects may have no names • Files in transition; files to be deleted upon close, etc. • No replication, not distributed • Except mounted directories Introduction to Naming

  23. DNS — Domain Name Service • Maps names of the form www.cs.wpi.edu to IP addresses • Hierarchical • Structured names denote hierarchy • DNS hierarchy versus file hierarchy • In file hierarchy, we often • Cache part of path name • Set up working directory • Use relative names • In DNS hierarchy, we usually • Use fully qualified names • Cache levels only forperformance Introduction to Naming

  24. DNS (continued) • Designed to be scalable to large numbers of names and objects • Usable world-wide • Distributed and replicated • Robust against failures of individual servers • Inconsistency is tolerable • Infrequent changes • Local administration of levels within hierarchy Introduction to Naming

  25. Common DNS Queries • Host name resolution • E.g, www.dcs.qmul.ac.uk IP address • Multiple IP addresses possible for one name • Mail host location • E.g, tom@dcs.qmul.ac.uk  mail server name • Multiple mail servers possible for one domain • Multiple domains for one mail server Introduction to Naming

  26. Other DNS Queries • Aliases • Reverse resolution • IP address  host name • Host information • Not used so often • “Well-known” services • FTP, telnet, etc. • Other attributes Introduction to Naming

  27. DNS Naming Hierarchy Introduction to Naming

  28. Resolving DNS names to IP addresses • Two approaches:– • Iterative • Recursive Introduction to Naming

  29. Iterative Resolution of Names E.g., ftp.cs.vu.nl Introduction to Naming

  30. Recursive Resolution of Names E.g., ftp.cs.vu.nl Introduction to Naming

  31. Hybrid Resolution Possible • E.g., global server may not be willing to recursively resolve ftp.cs.vu.nl • Returns name server for nl only • nl server may not be willing to recursively resolve ftp.cs.vu • Returns name server for vu only • vu server resolves ftp.csrecursively within vu.nl domain Introduction to Naming

  32. Text file containing records Each record is {Name, Type, value(s)} DNS Domain Registry Database Introduction to Naming

  33. Example Introduction to Naming

  34. DNS Implementation • One master copy per domain or subdomain • Edited manually by system administrator • Using text editor or GUI tool • Multiple slave copies • Automatically copied / updated periodically from master • Stored in file on slave server, reloaded up restart • Caching in DNS clients • Lots and lots of caching • Entries include TTL (time-to-live) specification Master and slave copies areauthoritative I.e., the truth! Cached copies are notauthoritative Pointer to authoritative copyis sometimes provided Introduction to Naming

  35. Implementation in Linux/Unix • BIND — Berkeley Internet Name Domain • http://www.bind9.net/ • named — the Name Daemon • Implements local DNS service • Multiple databases • Primary or secondary • Secondary database points back to primary • Pointer to “higher level” service • For resolving names not in own database Introduction to Naming

  36. Example • Want to find www.cs.wpi.edu • My DNS contacts DNS server 68.87.71.226 • A Comcast server specified in my DHCP lease • Comcast DNS service • Almost certainly has root (global) domain in cache • Probably has many .edu entries in cache (very large) • Possibly has .wpi.edu in cache (many local users) • May have .cs.wpi.edu • Consults cache or official server for IP address Introduction to Naming

  37. Example (continued) C:\>nslookup cs.wpi.edu Server: cns.chelmsfdrdc2.ma.boston.comcast.net Address: 68.87.71.226 Non-authoritative answer: Name: cs.wpi.edu Address: 130.215.28.181 Introduction to Naming

  38. Some Special Cases • Google • Yahoo • MSN • Need to distribute names geographically • Need to distribute different addresses for same name • Special handling of replicated databases • Implementation:– • Beyond the scope of this course Introduction to Naming

  39. Naming Privacy • Problem:– corporations need to have own domains • www.merl.com • Some public hosts – mail server, web server, etc. • Does not want to expose names of internal hosts to outside world • E.g., proprietary stuff • But wants to make them visible internally • hotspur.merl.com Introduction to Naming

  40. Solution • Two name services for same domain name! • Internal • External • External — visible to Internet (DMZ) • Database contains only a few names • Points to other internet DNS’s for resolution of internet names • Internal — seen only by internal hosts • Database contains all internal names • Points to external version for resolution of internet names Introduction to Naming

  41. Result • Internal names can be resolved internally, not externally • hotspur.merl.com • Internal names and IP addresses are invisible on Internet • All external names can be resolved internally • Two levels of indirection Introduction to Naming

  42. Comments – Domain Name Service • Root servers are highly replicated • Maintained by internet authorities • Change infrequently • First level domain servers are highly replicated • Maintained by internet or national authorities • Domains come and go; most are static • Very large – .com, .net, .edu • Everyone caches root and first level domain names Introduction to Naming

  43. Summary – Domain Name Service • Hierarchical • Distributed and replicated • Decentralized below top-level and first-level domains • Scalable • Supports 108 to 109 nodes • Reading • Tanenbaum, §8.4 Introduction to Naming

  44. Another Example Grapevine Registry System Introduction to Naming

  45. Questions? Introduction to Naming

More Related