Distributed Systems Principles and Paradigms Chapter 04 Naming

Distributed Systems

Principles and Paradigms

Chapter 04Naming

• 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.


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


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.


• 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.


Name ResolutionName 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


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)


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.


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).


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.


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


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.


Name Space Implementation (2/2)


Iterative Name Resolution


• 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


• 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


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 – 17A Naming/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 4-12. The most important types of resource records forming the contents of nodes in 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

04 – 17B Naming/4.1 Naming Entities

Figure 4-13.

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.

Attribute Abbr. Value

Country C NL

Locality L Amsterdam

Organization O Vrije Universiteit

OrganizationalUnit OU Math. & Comp. Sc.

CommonName CN Main server

Mail_Servers -- 130.37.24.6, 192.31.231,192.31.231.66

FTP_Server -- 130.37.21.11

WWW_Server -- 130.37.21.11

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

Attribute Value Attribute Value

Country NL Country NL

Locality Amsterdam Locality Amsterdam

Organization Vrije Universiteit Organization Vrije Universiteit

OrganizationalUnit Math. & Comp. Sc. OrganizationalUnitMath. & Comp. Sc.

CommonName Main server CommonName Main server

Host_Name star Host_Name zephyr

Host_Address 192.31.231.42 Host_Address 192.31.231.66

04 – 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)

Documents

Distributed Systems Principles and Paradigms Chapter 04 Naming