Distributed Systems Principles and Paradigms Chapter 04 Naming

Names, identifiers, and addresses Name resolution Name space implementation Naming Entities 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

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: - P1 Each identifier refers to at most one entity - P2 Each entity is referred to by at most one identifier - P3 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? Identifiers 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

Type of the entity An identifier for that entity Address of the entity’s location Nicknames... Name Space (2/2) Observation: We can easily store all kinds of attributes in a node, describing aspects of the entity the node represents: 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 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

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 Name Linking (1/2) 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 n5. 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 04 – 14 Naming/4.1 Naming Entities resolve(dir, [name1,…, nameK]) is sent to Server0 responsible for dir Server0 resolves resolve(dir, name1) → dir1, returning the identification (address) of Server1, which stores dir1. Client sends resolve(dir1,[name2,…, nameK]) to Server1 etc.

Recursive Name Resolution 04 – 15 Naming/4.1 Naming Entities resolve(dir,[name1,…,nameK]) is sent to Server0 responsible for dir Server0 resolves resolve(dir, name1) → dir1, and sends resolve(dir,[name2,…,nameK]) to Server1, which stores dir1. Server0 waits for the result from Server1, and returns it to the client

04 – 16 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.

Example 1: Internet Domain Name System (DNS) 04 – 17ANaming/4.1 Naming Entities - 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

DNS Resource Records Figure The most important types of resource records forming the contents of nodes in the DNS name space. Type of record Associated entity Description SOAZoneHolds information on the represented zone AHostContains an IP address of the host this node represents MXDomainRefers to a mail server to handle mail addressed to this node SRVDomainRefers to a server handling a specific service NSZoneRefers to a name server that implements the represented zone CNAMENodeSymbolic link with the primary name of the represented node PTRHostContains the canonical name of a host HINFOHostHolds information on the host this node represents TXTAny kindContains any entity-specific information considered useful 04 – 17B Naming/4.1 Naming Entities

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

- 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 – 18A Naming/4.1 Naming Entities Example 2: X.500 Directory Service (1)

A simple example of a X.500 directory entry using X.500 naming conventions. AttributeAbbr.Value CountryCNL LocalityLAmsterdam OrganizationOVrije Universiteit OrganizationalUnitOUMath. & Comp. Sc. CommonNameCNMain server Mail_Servers , , FTP_Server WWW_Server X.500 Directory Entry Example 04 – 18B Naming/4.1 Naming Entities

A Part of Directory Information Tree 04 – 18C Naming/4.1 Naming Entities

Two directory entries having Host_Name as RDN AttributeValueAttributeValue CountryNLCountryNL LocalityAmsterdamLocalityAmsterdam OrganizationVrije UniversiteitOrganizationVrije Universiteit OrganizationalUnitMath. & Comp. Sc.OrganizationalUnit Math. & Comp. Sc. CommonNameMain serverCommonNameMain server Host_NamestarHost_Namezephyr Host_Address Host_Address – 18D Naming/4.1 Naming Entities

- 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 – 18E Naming/4.1 Naming Entities Example 2: X.500 Directory Service (2)