Distributed Systems Principles and Paradigms Chapter 04 Naming

Distributed Systems Principles and Paradigms Chapter 04 Naming

Naming Entities • Names, identifiers, and addresses • Name resolution • Name space implementation 04 – 1 Naming/4. 1 Naming Entities

Naming Essence: Names are used to denote entities in a distributed system. To operate on an entity, we need to access it at an access point. Access points are entities that are named by means of an address. Note: A location-independent name for an entity E, is independent from the addresses of the access points offered by E. 04 – 2 Naming/4. 1 Naming Entities

Identifiers Pure name: A name that has no meaning at all; it is just a random string. Pure names can be used for comparison only. Identifier: A name having the following properties: - P 1 Each identifier refers to at most one entity - P 2 Each entity is referred to by at most one identifier - P 3 An identifier always refers to the same entity (prohibits reusing an identifier) Observation: An identifier need not necessarily be a pure name, i. e. , it may have content. Question: Can the content of an identifier ever change? 04 – 3 Naming/4. 1 Naming Entities

Name Space (1/2) Essence: a graph in which a leaf node represents a (named) entity. A directory node is an entity that refers to other nodes. Note: A directory node contains a (directory) table of (edge label, node identifier) pairs. 04 – 4 Naming/4. 1 Naming Entities

Name Space (2/2) Observation: We can easily store all kinds of attributes in a node, describing aspects of the entity the node represents: • • • Type of the entity An identifier for that entity Address of the entity’s location Nicknames. . . Observation: Directory nodes can also have attributes, besides just storing a directory table with (edge label, node identifier) pairs. 04 – 5 Naming/4. 1 Naming Entities

Name Resolution - the process of looking up a name Problem: To resolve a name we need a directory (initial) node. How do we actually find that initial node? Closure mechanism: The mechanism to select the implicit context from which to start name resolution: Question: Why are closure mechanisms always implicit? Observation: A closure mechanism may also determine how name resolution should proceed 04 – 6 Naming/4. 1 Naming Entities

Name Linking (1/2) Hard link: What we have described so far is a path name: a name that is resolved by following a specific path in a naming graph from one node to another. Soft link: Allows a node O to contain a name of another node: • First resolve O’s name (leading to O) • Read the content of O, yielding name • Name resolution continues with name Observations: • The name resolution process determines that we read the content of a node, in particular, the name in the other node that we need to go to. • One way or the other, we know where and how to start name resolution given name 04 – 7 Naming/4. 1 Naming Entities

Name Linking (2/2) Observation: the path name /home/steen/keys, which refers to a node containing the absolute path name /keys, is a symbolic link to node n 5. 04 – 8 Naming/4. 1 Naming Entities

Merging Name Spaces (1/3) Problem: We have different name spaces that we wish to access from any given name space. Solution 1: Introduce a naming scheme by which pathnames of different name spaces are simply concatenated (URLs). 04 – 9 Naming/4. 1 Naming Entities

Merging Name Spaces (2/3) Solution 2: Introduce nodes that contain the name of a node in a “foreign” name space, along with the information how to select the initial context in that foreign name space. Mount point: (Directory) node in naming graph that refers to other naming graph Mounting point: (Directory) node in other naming graph that is referred to. 04 – 10 Naming/4. 1 Naming Entities

Merging Name Spaces (3/3) Solution 3: Use only full pathnames, in which the starting context is explicitly identified, and merge by adding a new root node (DCE’s Global Name Space). Note: In principle, you always have to start from the new root 04 – 11 Naming/4. 1 Naming Entities

Name Space Implementation (1/2) Basic issue: Distribute the name resolution process as well as name space management across multiple machines, by distributing nodes of the naming graph. Consider a hierarchical naming graph and distinguish three levels: Global layer: Consists of the high-level directory nodes. Main aspect is that these directory nodes have to be jointly managed by different administrations Administrational layer: Contains mid-level directory nodes that can be grouped in such a way that each group can be assigned to a separate administration. Managerial layer: Consists of low-level directory nodes within a single administration. Main issue is effectively mapping directory nodes to local name servers. 04 – 12 Naming/4. 1 Naming Entities

Name Space Implementation (2/2) 04 – 13 Naming/4. 1 Naming Entities

Iterative Name Resolution • resolve(dir, [name 1, …, name. K]) is sent to Server 0 responsible for dir • Server 0 resolves resolve(dir, name 1) → dir 1, returning the identification (address) of Server 1, which stores dir 1. • Client sends resolve(dir 1, [name 2, …, name. K]) to Server 1 • etc. 04 – 14 Naming/4. 1 Naming Entities

Recursive Name Resolution • resolve(dir, [name 1, …, name. K]) is sent to Server 0 responsible for dir • Server 0 resolves resolve(dir, name 1) → dir 1, and sends resolve(dir, [name 2, …, name. K]) to Server 1, which stores dir 1. • Server 0 waits for the result from Server 1, and returns it to the client 04 – 15 Naming/4. 1 Naming Entities

Caching in Recursive Name Resolution • Also see Figure 4 -11 for the comparison between recursive and iterative name resolution with respect to communication costs. 04 – 16 Naming/4. 1 Naming Entities

Example 1: Internet Domain Name System (DNS) - used for looking up IP addresses of hosts and mail servers in Internet - comparable to a telephone book (white pages) for looking up phone numbers - DNS name space is hierarchically organized as a rooted tree - The contents of a node is formed by a collection of resource records - Multiple (primary, secondary, etc. ) DNS servers are usually deployed for an organization to increase availability - nslookup is a utility for querying DNS service 04 – 17 A Naming/4. 1 Naming Entities

DNS Resource Records 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 Figure 4 -12. The most important types of resource records forming the contents of nodes in the DNS name space. 04 – 17 B Naming/4. 1 Naming Entities

Sample DNS Records Figure 4 -13. An excerpt from the DNS database for the zone cs. vu. nl. 04 – 17 C

Example 2: X. 500 Directory Service (1) - ITU standard for directory services - provides directory service based on a description of properties instead of a full name (e. g. , yellow pages in telephone book) - an X. 500 directory entry is comparable to a resource record in DNS - Each record is made up of a collection of (attribute, value) pairs - The collection of all entries is called Directory Information Base (DIB) - Each entry in a DIB can be looked up using a sequence of naming attributes, which forms a globally unique name called Distinguished Name (DN). Each naming attribute is called Relative Distinguished Name (RDN) - e. g. , /C=KR/O=POSTECH/OU=Dept. of CSE is analogous to the DNS name cse. postech. ac. kr - X. 500 also forms a hierarchy of the collection of entries called Directory Information Tree (DIT) 04 – 18 A Naming/4. 1 Naming Entities

X. 500 Directory Entry Example Attribute Abbr. Value Country C NL Locality L Amsterdam Organization O Vrije Universiteit Organizational. Unit OU Math. & Comp. Sc. Common. Name CN Main server Mail_Servers -- 130. 37. 24. 6, 192. 31. 231. 66 FTP_Server -- 130. 37. 21. 11 WWW_Server -- 130. 37. 21. 11 A simple example of a X. 500 directory entry using X. 500 naming conventions. 04 – 18 B Naming/4. 1 Naming Entities

A Part of Directory Information Tree 04 – 18 C Naming/4. 1 Naming Entities

Two directory entries having Host_Name as RDN Attribute Value Country NL Locality Amsterdam Organization Vrije Universiteit Organizational. Unit Math. & Comp. Sc. Common. Name Main server Host_Name star Host_Name zephyr Host_Address 192. 31. 231. 42 Host_Address 192. 31. 231. 66 04 – 18 D Naming/4. 1 Naming Entities

Example 2: X. 500 Directory Service (2) - DIT is usually partitioned and distributed across multiple servers known as Directory Service Agents (DSA) - Clients are known as Directory User Agents (DUA) - Directory Access Protocol (DAP) is used between DUA and DSA to insert/lookup/modify/delete entries in DSA - traditionally implemented using OSI protocols - Lightweight Directory Access Protocol (LDAP) - implemented on top of TCP - parameters of operations are passed as strings - has become a de facto standard for Internet-based directory services for various applications 04 – 18 E Naming/4. 1 Naming Entities