860 likes | 1.1k Views
Naming. Chapter 4. Why Naming?. Names are needed to Identify entities Share resources Refer to locations, etc. It is necessary to resolve names What does human-friendly name correspond to Need a naming system In distributed systems, naming system itself is often distributed.
E N D
Naming Chapter 4 Chapter 4 Naming 1
Why Naming? • Names are needed to • Identify entities • Share resources • Refer to locations, etc. • It is necessary to resolve names • What does human-friendly name correspond to • Need a naming system • In distributed systems, naming system itself is often distributed Chapter 4 Naming 2
Outline of Chapter • General naming issues • Human-friendly names • Naming and mobility • Such as mobile telephony • Unreferenced objects • How to remove unused names Chapter 4 Naming 3
Names, Identifiers, Addresses • A name is a string of bits that refers to an entity • An entity is “practically anything” • Entities can be operated on • To operate on entity, must know an access point • Access point is just another entity! • Name of an access pt is an address Chapter 4 Naming 4
Names, Identifiers, Addresses • Example • Telephone is an access point • Telephone number is address • Distributed systems example • Server is an access point • IP address/port number is address • Mobility creates special problems… Chapter 4 Naming 5
Names, Identifiers, Addresses • Address is a special kind of name • For an access point • Access point associated with an entity • Why not use address as entity name? • Entities may change access points • For example, IP address vs MAC address • Entity may offer more than one access point • For example, Web service with multiple servers • An entity name that is independent of its address is location independent Chapter 4 Naming 6
Names, Identifiers, Addresses • An identifier is a special type of name • Identifier refers to at most one entity • Entity referred to by at most one identifier • Identifier is never reused • That is, identifiers are unambiguous • “Mark Stamp” is not an identifier • Telephone number is not an identifier • Examples of identifiers? Chapter 4 Naming 7
Names, Identifiers, Addresses • Human-friendly names? • File names • www.google.com • Other? • Human unfriendly names? • Memory locations • Other? Chapter 4 Naming 8
Name Spaces • Organization of names in distributed system is a name space • Represented as a labeled directed graph • Usually restricted to directed acyclic graphs • Leaf node is a named entity • Has no outgoing edge • Leaf node stores address and/or state • Directory node has a table • Can have many outgoing edges • Root node has no incoming edges • Usually only one Chapter 4 Naming 9
Name Spaces • Naming graph with single root node n0 • Complete path is a path name • Begins with n0, then it’s an absolute path • Otherwise, a relative path Chapter 4 Naming 10
Name Spaces • Names organized in a name space • Implies that a name is defined relative to a directory node • Global name denotes same entity no matter where the name is used • Local name depends on where it’s used • In other words, a local name is a relative name whose directory is known Chapter 4 Naming 11
Name Spaces • Example: UNIX file system • A single root node • File directory is a directory node • File is a leaf node Chapter 4 Naming 12
Name Resolution • Given path name, must be able to access the specified node • This process is name resolution • How does this work? • Short answer: traverse the directed graph • Long answer: see the book • But, must know where to start • For example, how to resolve 7127552339 ? • First, must know it’s a phone number • I.e., must know root node of appropriate graph Chapter 4 Naming 13
Linking and Mounting • An alias is another name for something • Can have multiple paths to same node, or… • A symbolic link in naming graph (as above) Chapter 4 Naming 14
Linking and Mounting • Combine different name spaces • Need directory node in other name space • Node storing node identifier of foreign name space is mount point • Directory node in foreign name space is mounting point (usually root node) • Important in distributed systems! Chapter 4 Naming 15
Linking and Mounting • In distributed system… • To mount foreign name space, need • Name of access protocol • Name of server • Name of mounting point • Name resolution required Chapter 4 Naming 16
Linking and Mounting • Consider Network File System (NFS) • Distributed file system • Discussed in detail in chapter 10 • Access a file by NFS URL • For example, nfs://flits.cs.vu.nl//home/steen • File (directory) /home/steen • On server flits.cs.vu.nl • Accessed using NFS protocol • Access protocol, server, mounting point? Chapter 4 Naming 17
Linking and Mounting • Consider (machine A) /remote/vu/mbox • On A, nfs://flits.cs.vu.nl//home/steen • Then to machine B… Chapter 4 Naming 18
Linking and Mounting • DEC Global Name Service (GNS) • Insert a new root node • Existing names change • Can avoid changing names • See book Chapter 4 Naming 19
Name Space Implementation • Naming service • To add, remove, lookup names • Implemented on name server(s) • In distributed system, naming service itself may be distributed • Name space is heart of naming service • Name space distribution (organization) • Name resolution Chapter 4 Naming 20
Name Space Distribution • Usually organized hierarchically • Assume one root • Three logical layers • Global layer root and nearby (very stable) • Administrational layer directory nodes in one organization (relatively stable) • Managerial layer typically, hosts in one network (not stable) • For example, DNS Chapter 4 Naming 21
Name Space Distribution • DNS name space in three layers • Subtle performance issues • Different requirements at each layer Chapter 4 Naming 22
Name Space Distribution Item Global Administrational Managerial • Comparison of name servers Geographical scale of network Worldwide Organization Department Total number of nodes Few Many Vast numbers Responsiveness to lookups Seconds Milliseconds Immediate Update propagation Lazy Immediate Immediate Number of replicas Many None or few None Is client-side caching applied? Yes Yes Sometimes Chapter 4 Naming 23
Name Resolution • Two approaches… • Iterative name resolution • Server sends result back to client • More work for client • Recursive name resolution • Server contacts next name server • More work for servers Chapter 4 Naming 24
Iterative Name Resolution • Caching limited to client Chapter 4 Naming 25
Recursive Name Resolution • Caching is more effective (next slide) • More efficient communication (slide after next) Chapter 4 Naming 26
Name Resolution • Recursive name resolution of <nl, vu, cs, ftp> • Name servers cache intermediate results Chapter 4 Naming 27
Name Resolution • Recursive versus iterative name resolution • Comparing communication costs Netherlands San Jose Chapter 4 Naming 28
Examples • DNS traditional naming service • Hierarchical, rooted tree • Like a white pages service for Internet • You should be familiar with this • Read it! • X.500 directory service • Find an entity that fits a description • Like a yellow pages service Chapter 4 Naming 29
DNS Name Space • Hierarchical, rooted tree • Each node has 1 incoming edge (except the root) • Incoming edge used as name of node • A subtree is a domain • Path name is a domain name • Can be relative or absolute • Node contains resource records Chapter 4 Naming 30
DNS Name Space • Most important types of resource records Chapter 4 Naming 31
DNS Implementation • DNS includes • Global layer • Administrational layer • Managerial layer not formally in DNS • Read the details Chapter 4 Naming 32
DNS Implementation • Excerpt from DNS database for the zone cs.vu.nl Chapter 4 Naming 33
DNS Implementation • Description for vu.nl domain • This domain contains cs.vu.nl domain Chapter 4 Naming 34
X.500 Name Space • Each record consists of • (attribute, value) pairs • Attribute can have multiple values • Directory Information Base (DIB) • All entries in X.500 directory service • Each attribute is a Relative Distinguished Name (RDN) • Complete record is globally unique • So it can be looked up Chapter 4 Naming 35
X.500 Name Space • Example of X.500 directory entry • Unique name: Country, Organization, OrganizationalUnit • /C=NL/O=Vrije Universiteit/OU=Math. & Comp. Sc. • Analogous to DNS: nl.vu.cs Chapter 4 Naming 36
X.500 Name Space • Globally unique names form hierarchy • Directory Information Tree (DIT) • The naming graph in X.500 • Node can act as directory • More than one child • See next slide Chapter 4 Naming 37
X.500 Name Space • Part of directory information tree • “N” acts as directory… • …and as a node Chapter 4 Naming 38
X.500 Name Space • Two entries with Host_Name as RDN Chapter 4 Naming 39
X.500 Implementation • Like DNS • But more lookup operations to search DIB • For example, can search for all “main servers” at Vrije Universiteit • See example in book • But, need to access many leaf nodes • Leaf nodes might be distributed • This could be expensive! Chapter 4 Naming 40
X.500 in the Real World • X.500 • Uses Directory Access Protocol (DAP) • Runs over OSI • Therefore, it is “heavyweight” • What if you like X.500… • …but need to use it in the real world? • Need something lightweight… Chapter 4 Naming 41
LDAP • Lightweight Directory Access Protocol • Application level protocol • Implemented on top of TCP • Lookup, update, passed as strings • No separate encoding required • LDAP is defacto standard • We used LDAP at my startup company Chapter 4 Naming 42
Mobility • What is different in mobile case? • Names change frequently • Why is this an issue? • Consider DNS • Global layer and admin. layers assume names change infrequently • So replication and caching are used • For mobile, something else is needed… • But what? Chapter 4 Naming 43
Mobility • Consider DNS • ftp.cs.vu.nl • Local cache probably has cs.vu.nl • One request to find desired address • Now spse ftp server moves • If it stays in cs.vu.nl, only local changes • What if it moves to ftp.cs.unisa.edu.au ? Chapter 4 Naming 44
Mobility • Spse ftp.cs.vu.nl moves to ftp.cs.unisa.edu.au • What to do? • Forget about cs.vu.nl • Users won’t be happy • Record new address under cs.vu.nl • If it moves locally, update is not local • Turn cs.vu.nl into a symbolic link • In effect, 2 lookups • But it gets no worse if it moves again • Either way, name can never change Chapter 4 Naming 45
Mobility • Better idea • Give up on DNS-like approach • Add an intermediate step • Assign non-human-friendly identifier • Then • Name service converts human-friendly name into identifier • Location service converts identifier to current address Chapter 4 Naming 46
Naming versus Locating • DNS-like mapping between name and address • Two-level mapping using identifiers Chapter 4 Naming 47
Mobility • But this begs the question • How to build location service? • Simple solutions • Broadcasting and multicasting • Forwarding pointers • Complicated (?) solutions • Home-based approaches • Hierarchical approaches Chapter 4 Naming 48
Broadcasting and Multicasting • Spse mobility restricted to LAN • Broadcasting is efficient on LAN • Use ARP to locate entity • Does not scale well • Can do similar thing at network layer • Use multicasting • Mobile computer gets dynamic IP address and joins multicast group • Multicast group acts as location service Chapter 4 Naming 49
Forwarding Pointers • Another simple approach • Forwarding pointers • When moving from A to B, leave a pointer at A to new location B • Naming service still points to A • Simple, yes, but… • Chain might get long • Every link in chain must be maintained Chapter 4 Naming 50