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:
- 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?
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
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 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
• 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.
04 – 14
Naming/4.1 Naming Entities
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
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 – 17A
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 – 17B
Naming/4.1 Naming Entities
Sample DNS Records
Figure 4-13.
An excerpt
from the
DNS
database
for the
zone
cs.vu.nl.
04 – 17C
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 – 18A
Naming/4.1 Naming Entities
X.500 Directory Entry Example
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
A simple example of a X.500 directory entry
using X.500 naming conventions.
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.
OrganizationalUnit
Math. & 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
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 – 18E
Naming/4.1 Naming Entities