DISTRIBUTED SYSTEMS Lecture 5 – Naming Huber Flores, Xiang Su, Pan Hui {firstname.lastname}@helsinki.fi Helsinki, Finland, 2019. 2 NAMING Helsinki, Finland, 2019. 3 Agenda 5.1 NAMES, IDENTIFIERS, AND ADDRESSES 5.2 FLAT NAMING 5.2.1 Simple solutions 5.2.2 Home-based approaches 5.3 STRUCTURED NAMING 5.3.1 Name spaces 5.3.2 Name resolution 5.3.3 The implementation of a name space 5.3.4 Example: The Domain Name System 5.4 ATTRIBUTE-BASED NAMING 5.4.1 Directory services 5.4.2 Hierarchical implementationsHelsinki, Finland,: LDAP2019. 4 Names, identifiers, and addresses • Name: string of bits for referring to an entity – Hosts, printers, files, processes, users, locations, mailboxes, web pages, … – Entities can be operated on via an access point • The name of an access point is address • An entity can have multiple access points – Location-independent names (independent of address) • Identifier: an unambiguous name – Refers to at most one entity – Each entity is referred to by at most one identifier – Always refers to the same entity (it is never re-used) • Human-friendly names: string of characters • Name-to-address binding maintained by naming service Helsinki, Finland, 2019. 5 Flat naming • Unstructured or flat names – Identifiers are random bit strings – Do not contain any information on how to locate the access point • Simple solutions for resolving names and locating entities – Broadcasting and multicasting • Effective in LANs, e.g. ARP (Address Resolution Protocol) • Can never scale beyond local-area networks – Forwarding pointers Helsinki, Finland, 2019. 6 Forwarding pointers • Moving entity leaves behind a reference to its new location – Forwarding pointers using (client stub, server stub) pairs • Migration is transparent to client – Challenges • Long chains are not fault tolerant • Burden on intermediate locations • Vulnerability to broken Helsinki,links Finland, 2019. 7 Forwarding pointers • Storing a shortcut in a client stub Helsinki, Finland, 2019. 8 Home-based approaches • Principle of Mobile IP – Home agent (HA) in home location keeps track of current location of a mobile host (temporary care-of-address) Helsinki, Finland, 2019. 9 Home-based approaches • Problems with home-based approaches – Home address has to be supported for entity’s lifetime. – Home address is fixed ⇒ unnecessary burden when the entity permanently moves – Poor geographical scalability (entity may be next to client) Helsinki, Finland, 2019. 10 Hierarchical Location Services (HLS) • Build a large-scale search tree for which the underlying network is divided into hierarchical domains. Each domain is represented by a separate directory node. Helsinki, Finland, 2019. 11 Hierarchical Location Services (HLS) • Address of entity E is stored in a leaf or intermediate node • Intermediate nodes contain a pointer to a child if and only if the subtree rooted at the child stores an address of the entity • The root knows about all entities Helsinki, Finland, 2019. 12 HLS: Lookup operation • Start lookup at local leaf node • Node knows about E ⇒ follow downward pointer, else go up • Upward lookup always stops at root Helsinki, Finland, 2019. 13 HLS: Insert operation (a) An insert request is forwarded to the first node that knows about entity E. (b) (b) A chain of forwarding pointers to the leaf node is created Helsinki, Finland, 2019. 14 Hierarchical location services • Principle of distributing logical location servers Domain Helsinki, Finland, 2019. 15 Structured naming: Name spaces • A name space can be presented as labeled directed graph – Two types of nodes • Leaf node: named entity (no outgoing edges) • Directory node: entity with outgoing edges stored in directory table (edge label, node identifier) – Root (node): only outgoing, no incoming edges – Path name: N:<label-1, label-2, ..., label-n> • If 1st node root ® absolute path name, otherwise relative path name – Global name (/home/steen) vs local name (./steen) A general naming graph with a single root node (directed acyclic graph, no cycles) Helsinki, Finland, 2019. 16 Name spaces • Naming in UNIX file system – Directory node represents a file directory • Each directory is implemented as a file – Leaf node represents a file – Index nodes (inode) • Contents: location of associated file on the disk, owner, time of creation, time of last modification, protection etc. • Index # corresponds to node identifier in the naming graph – #0 root directory The general organization of the Unix file system implementation on a logic disk of contiguous disk blocks Helsinki, Finland, 2019. 17 Name resolution • To resolve a name, we need a directory node. • Name resolution for path N: <label-1, label-2, ..., label-n> – Name resolution starts at N – Node identifier n1 corresponding to label-1 is looked up in the directory table of N – Node identifier n2 corresponding to label-2 is looked up in the directory table of n1 – ... – If path exists, resolution stops at the last node referred to by label-n, returning the content of that node Helsinki, Finland, 2019. 18 Closure mechanism • Need to know how and where to start name resolution • Unix: the first inode in the logical file system is the root directory • Example: – www.distributed-systems.net: start at a DNS name server – /home/maarten/mbox: start at the local NFS file server (possible recursive search) Helsinki, Finland, 2019. 19 Linking and mounting • Alias: another name for the same entity – Can be implemented as a hard link or a symbolic link /keys and /home/steen/keys /home/steen/keys is are hard links to node n5 symbolic link to node n5 Helsinki, Finland, 2019. 20 Linking and mounting • Merging name spaces via mounting – A directory node (mount point) stores the identifier of a directory node from a foreign name space (mounting point) • Mounting point is typically the root of the foreign name space – Requires • Name of access protocol • Name of server • Name of mounting point in foreign name space Helsinki, Finland, 2018. Helsinki,Mounting Finland, 2019.remote name spaces in NFS 21 Implementation of a name space • Name-to-address-binding maintained by naming service • Naming service implemented by name servers • Names are organized into a name space • Name space distribution – Global layer • Root + its children – Administrational layer • Nodes managed by a single organization – Managerial layer Helsinki,An example Finland, 2018. partitioning of the DNS name space Helsinki, Finland, 2019. 22 Implementation of a name space • Comparison between name servers for implementing nodes from a large-scale name space Helsinki, Finland, 2019. 23 Implementation of name resolution • Iterative name resolution – Caching restricted to client’s name resolver ® different clients need to do complete resolution – Compromise: intermediate local name server shared by all clients caches results Helsinki, Finland, 2019. 24 Implementation of name resolution • Iterative name resolution Helsinki, Finland, 2019. 25 Implementation of name resolution • Recursive name resolution Helsinki, Finland, 2019. 26 Implementation of name resolution • Recursive name resolution (cont.) – Caching of intermediate results for subsequent lookups Helsinki, Finland, 2019. 27 Implementation of name resolution • Comparison of recursive and iterative name resolution with respect to communication costs – Recursive is typically more efficient Helsinki, Finland, 2019. 28 Example: The Domain Name System • Hierarchically organized name space with each node having exactly one incoming edge → edge label = node label • Subtree is a zone (~domain) managed by a primary (authoritative) name server providing authoritative resource records (can also have one or more secondary name servers) • Domain ~ a subtree; domain name ~ a path name to a domain’s root node Helsinki, Finland, 2019. 29 Example: The Domain Name System Local name servers • Do not strictly belong to hierarchy • Each ISP (e.g. company, university) has one – Also called “default name server” • When a host makes a DNS query, query is sent to its local DNS server – Acts as a proxy, forwards query into hierarchy Helsinki, Finland, 2019. 30 Example: The Domain Name System • Principal service: IP address Û domain name translation –For hosts, routers, applications • Hierarchical name space –Distributed database implemented in hierarchy of many name servers • Application-level protocol –Complexity at the network’s edGe (end-to-end) • Scalable (throuGh hierarchy & cachinG) • Replicated for reliability • Requires administration Helsinki, Finland, 2019. 31 DNS: Example • Mapping of email address to IP address Helsinki, Finland, 2019. 32 DNS: Additional services • Host aliasing (canonical and alias names) – Host with complicated name can have aliases (often mnemonic) – relay1.west-coast.enterprise.com (canonical hostname) may have two aliases {enterprise.com, www.enterprise.com} – [email protected] instead of [email protected] coast.hotmail.com • Load distribution – Replicated web servers (set of IP addresses for one canonical name) • Content Distribution Networks (e.g. Akamai) • Busy sites such as www.cnn.com are replicated over multiple servers HelsinKi, Finland, 2019. 33 DNS: Why not centralized? • Original Internet naming scheme – Master file (hosts.txt) of host names & their IPs • Maintained By Network Information Center (NIC) • DistriButed By email, or downloaded By FTP • Single point of failure • Traffic volume – 1991: 24-hour traces of a top-level server (.edu) • ~1 M requests/day -> ~ 11.5 requests/s – 2008: k-root server in London, 5000 requests/s • Distant centralized