Naming CSCI 69004900 Mounting Mounting Merging different namespaces

Naming CSCI 6900/4900

Mounting • Mounting – Merging different namespaces transparently • File system example – Directory node of one namespace stores identifier of directory node of another namespace – Mount Point – Directory node storing the foreign ID – Mounting Point – Directory node in foreign space – Resolution occurs by looking up mounting point and then accessing its directory table • Can be generalized to other namespaces as well

Mounting Foreign Namespaces • Namespaces on different servers possibly on different machines – Mounting might require network communication • Mounting requires at least three information – Name of access protocol – Name of server – Name of mounting point in foreign space • Each name needs to be resolved – Mounting point needs to be resolved by the foreign server – Three names are represented as a URL – Example: nfs: //flits. cs. vu. nl//home/steen

Mounting - Example Mounting remote name spaces through a specific process protocol. Tracing the resolution of /remote/vu/mbox

Mounting Alternative • Pioneered by Global Name Service • Add new root and make the existing root nodes the children of new root • Problem – Existing path names need to be changed • Solution – The root id (from where the resolution should normally start) is implicitly included in the path

Global Name Service

Name Space Implementation • Naming service – A service that lets users to add/delete and lookup names • In large distributed systems naming service has to be distributed • For convenience namespace is partitioned into logical layers – Global layer – Highest level nodes (root and first level children) – Administration layer – Directory nodes managed by single organization (Ex: Departmental nodes in UGA) – Managerial layer – Nodes of local network, shared files, etc.

Name Space Distribution An example partitioning of the DNS name space, including Internet-accessible files, into three layers.

Layers and their Characteristics • Global layer – Stability – Directory tables rarely change – High availability is critical – Permits high levels of caching, throughput is critical • Administrative Layer – Availability is critical – Permits high levels of caching – Response time should be fast • Managerial level – Client-side caching is in general less effective – Fast response time is crucial

Comparison of Layers Item Global Administrational Managerial 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 Number of replicas Many None or few None Is client-side caching applied? Yes Sometimes

Name Resolution - Implementation • Distribution affects name resolution implementation • Example: root: <nl, vu, cs, ftp, pub, globe, index. txt> • Two types – Iterative process and Recursive Process • Iterative Process – Each node resolves as much as it can and sends result to client, which contacts the next level of node • Recursive Process – Nodes do not return intermediate results to client – Contact next level of nodes obtain addresses and send complete results to the client

Iterative Name Resolution

Recursive Name Resolution (2)

Iterative Vs. Recursive Name Resolutions • Iterative – Shorter connection durations -> Less load on servers – Caching can be done only at the server -> High latency • Recursive – Longer connection duration -> High loads on servers – Permits caching at higher levels of nodes • High-level nodes can “learn” about lower level nodes • Permits shortcuts – Cheaper with respect to communication latency

Caching in Recursive Name Resolution Server for node Should resolve Looks up Passes to child Receives and caches Returns to requester cs <ftp> #<ftp> -- -- #<ftp> vu <cs, ftp> #<cs> <ftp> #<cs> #<cs, ftp> ni <vu, cs, ftp> #<vu> <cs, ftp> #<cs, ftp> #<vu, cs> #<vu, cs, ftp> root <ni, vu, cs, ftp> #<nl> <vu, cs, ftp> #<vu, cs> #<vu, cs, ftp> #<nl, vu> #<nl, vu, cs, ftp> Recursive name resolution of <nl, vu, cs, ftp>. Name servers cache intermediate results for subsequent lookups.

Implementation of Name Resolution (4) The comparison between recursive and iterative name resolution with respect to communication costs.

The Domain Name Service • Largest distributed naming service • Used for looking up host addresses and mail servers • Hierarchically organized as a rooted tree – Labels – 63 Characters; Pathnames – 256 characters – String representation – Listing labels from right to left separated by dots • Domain – Subtree of nametree – Domain name – Path to the root of the domain • Contents of node – Resource records

The DNS Name Space Type of record Associated entity Description SOA Zone Holds information on the represented zone A Host Contains an IP address of the host this node represents MX Domain Refers to a mail server to handle mail addressed to this node SRV Domain Refers to a server handling a specific service NS Zone Refers to a name server that implements the represented zone CNAME Node Symbolic link with the primary name of the represented node PTR Host Contains the canonical name of a host HINFO Host Holds information on the host this node represents TXT Any kind Contains any entity-specific information considered useful The most important types of resource records forming the contents of nodes in the DNS name space.

DNS Implementation • DNS namespace is divided into global layer and administration layer – Managerial layer no part of DNS • Each zone implemented by a name server – Replicated for availability – Updates happen only at primary name server – Lazy replication – Zone transfer • Database is made up of collection of files

DNS Implementation - Example An excerpt from the DNS database for the zone cs. vu. nl.

Reference to Subdomains Name Record type Record value cs. vu. nl NIS solo. cs. vu. nl A 130. 37. 21. 1 Part of the description for the vu. nl domain which contains the cs. vu. nl domain.