CHAPTER 5: Naming

Course Code: CoSc 4038

 Distributed
Naming Systems

 Names play a critical role in all computer systems

 Used to refer to locations
 Used to denote entities in a distributed system, and more
 A name in a distributed system is a string of bits or characters that is used
to refer to an entity.
 hosts, printers, disks, files, processes, webpages
 A name can be resolved to the entity it refers to.
 Name resolution system thus allows a process to access the named entity.
 In distributed system, the implementation of a naming system is often distributed
across multiple machines.
 How distribution is done has impact on the performance
 Distributed
Cont... Systems

 Entities can be operated on.

 Example: Printer provides operations for printing, pausing, cancelling etc.

 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.
 The name of an access point is an address
 E.g. A host running a specific server, its address formed by the combination of IP address and port number

 An entity may have multiple access points, and its access point may change
 Thus, the address of an access point should not be used to name the entity
 E.g., A person might has multiple phone numbers to reach him, and these number may be re-assigne
d to another person

 Therefore, what we need is a name for an entity that is independent from its addresses
 i.e., a location-independent name
 Distributed
Cont... Systems

 A location-independent name for an entity E , is independent from

the addresses of the access points offered by E .
 That refers to Identifier
 Identifier is 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)
 Distributed
The Central Theme of Naming Systems

 How to resolve names and identifiers to addresses ?

 In principle, a naming system maintains a name-to-address bin
ding in the form of mapping table
 However, a centralized table in a large network is not going to work
 The name resolution as well as the table is often distributed
across multiple machines
 E.g., www.kmu.edu.et is divided into multiple parts, and several DNS
servers are used during the resolution
 Will discuss the resolution of the following names
 Flat names, structured names, attribute-based names
 Distributed
Flat Names (Identifiers) Systems

 An identifier is often a string of random bits

 Does not contain any information on how to locate the access point of
its associated entity
 Problem:- given an essentially unstructured name (e.g., an identi
fier), how can we locate its associated access point?
 Simple solutions (broadcasting)
 Home-based approaches
 Distributed Hash Tables (structured P2P)
 Hierarchical location service
 Distributed
Simple solutions Systems

 Two simple solutions to locate the entity given an identifier

1. Broadcasting and multicasting (e.g., ARP)
 Broadcast the ID, requesting the entity to return its current address.
 Can never scale beyond local-area networks
 Requires all processes to listen to incoming location requests

2. Forwarding pointers
 A popular approach to locate mobile entities
 When an entity moves, it leaves a pointer to where it went
 Update a client’s reference when present location is found
 Distributed
Forwarding Pointers Systems

 Advantage:
 Dereferencing can be made transparent to client by following the pointer chain

 Disadvantages
 Geographical scalability problems:
 Chain can be very long for highly mobile entities
 Long chains are not fault tolerant
 High latency when dereferencing

 Need chain reduction mechanisms

 Update client's reference when the most recent location is found
 Distributed
Forwarding Pointers Systems
 Distributed
Forwarding Pointers Systems
 Distributed
Home-based solution Systems

 Let the home keep track where the entity is.

 Entity’s home address is registered at a naming service.
 In practice, the home location is often chosen to be the place where an entity wa
s created.
 The home registers the foreign address of the entity.
 Clients always contact the home first, and then continue with the foreign
location.
 Distributed
Home-Based Approaches Systems

 Figure 5-3. The principle of Mobile IP.

 Distributed
Problems With Home-Based Approaches Systems

 Home address has to be supported for entity’s lifetime.

 Home address is fixed.
 Unnecessary burden when the entity permanently moves.
 Poor geographical scalability.
 Entity may be next to client.
 Distributed
Distributed Hash Table (DHT)- Chord Systems

 In DHT-based system,
 Each node has an m-bit random identifier
 Each entity has an m-bit random key
 An entity with key k is located on a node with the smallest identifier that
satisfies id >= k, denoted as succ(k)
 The main issue in DHT-based systems is to efficiently resolve a key
k to the address of succ(k).
 Distributed
Distributed Hash Table (DHT)- Chord Systems

 Two approaches:
 linear approach and
 finger table
 In linear approach, let each node p keep track of the successor succ(p+ 1) as
well as its predecessor pred(p)
 whenever a node p receives a request to resolve key k, it will simply forw
ard the request to one of its two neighbours

15
 Distributed
Finger table Systems

 In the finger table approach, the first thing is to build the finger table.
 Each node p maintains a finger table FTp[] with at most m entries:
 FTp[i] = succ (p+ 2i−1)
 Note: FTp[i] points to the first node succeeding p by at least 2i−1

 To look up a key k, node p forwards the request to node with index j

satisfying
 q= FTp* j+ ≤ k< FTp[ j+1]
 If p < k < FTp[1], the request is also forwarded to FTp[1].
Distributed Hash Tables Distributed
Systems

Figure 5-4. Resolving key 26 from node 1 and key 12 from node 28 in a Chord system.
 Distributed
Exploiting Network Proximity Systems

 Problem:
 The logical organization of nodes in the overlay may lead to erratic mes
sage transfers in the underlying Internet
 Node k and node succ(k +1) maybe very far apart.
 Solutions:
 Topology-aware node assignment: When assigning an ID to a node, make sure
that nodes close in the ID space are also close in the network.
 Proximity routing: Maintain more than one possible successor, and forward to the
closest.
 Proximity neighbour selection: When there is a choice of selecting who your
neighbour will be, pick the closest one.
 Distributed
Hierarchical Location Services Systems
 The basic idea is to build a large-scale search tree for which the underlying network is divi
ded into hierarchical domains.
 Each domain is represented by a separate directory node.
 Leaf domains typically correspond to a local-area network or a cell.
 The root (directory) node knows all the entities.
 Each entity currently in a domain D is represented by a location record in the directory node dir(D) whi
ch is the entity’s current address or a pointer.
 Distributed
Hierarchical Approaches- organization Systems

 The address of an entity E is stored in a leaf or intermediate node.

 Intermediate nodes contain a pointer to a child iff the subtree rooted at the child stores
an address of the entity.
 An entity may have multiple addresses (e.g., if it is replicated).
 Distributed
Hierarchical Approaches - Lookup Operation Systems

 Start lookup at local leaf node.

 If node knows about entity E, follow downward pointer, otherwise go up.
 Upward lookup always stops at root.
 Distributed
Hierarchical Approaches – Insert operation Systems

 Consider an entity E that has created a replica in leaf domain D for which it needs to insert
its address.
 [A]. An insert request is forwarded to the first node that knows about entity E.
 [B]. A chain of forwarding pointers to the leaf node is created.
 Distributed
Structured Naming Systems

 Flat names are not convenient for humans to use

 As a result, naming systems often support structured names that
 Are composed from simple, human-readable names
 Example: file names, Internet domain names
 Structured names are often organized into what is called a name space
 Holds a collection of valid names recognized by a particular service.
 Examples: Phone numbers, DNS, URL etc
 It is represented by a labelled, directed graph with two types of nodes, leaf node
and directory node
 Distributed
Name Spaces (1) Systems

 A general naming graph with a single root node.

 Distributed
Name Resolution Systems

 Name resolution refers to the process of looking up a name, given a path name.
 name lookup returns the identifier of a node from where the name resolution process
continues
 To resolve a name we need a directory node.
 Problem:
 How do we actually find that (initial) node?
 Solution:
 Closure Mechanism: the mechanism to select the implicit context from which to start name resolution.
 Examples: www.kmu.edu.et: start at a DNS name server
/home/steen/mbox: start at the local file server

 Start from well known root directory, or start from home directory
 Distributed
Implementation of a Name Space Systems
 A name space is often implemented by name servers
 In LAN, a single name server is often good enough
 In large-scale distributed system, the implementation of a name space is often distributed over
multiple name servers

 A name space for large-scale distributed systems is often organized hierarchically

 Global layer
 often stable, represents organizations or groups of organizations

 Administrational layer
 Represents groups of entities in a single organization or admin. unit

 Managerial layer
 Nodes often change frequently, e.g., hosts in a local network
 May be managed by system administrators or end users
 Distributed
Name Space Distribution Systems

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

A comparison between name servers for implementing nodes from a large-scale name space
partitioned into a global layer, an administrational layer, and a managerial layer.
 Distributed
Implementation of Name Resolution Systems
 Assume that the (absolute) path name
 root: <nl, vu, cs, ftp> is to be resolved.
 Using URL notation, this path would correspond to
 ftp://cs.vu.nl

 Two ways to implement name resolution

 Iterative name resolution
 Hands over the complete name to the root name server.
 Intermediate result(i.e., the address of the next name server in the hierarchy) is returned back to the client’s
name resolver.
 The resolution process continues iteratively until the complete path is resolved.

 Recursive name resolution

 Intermediate results are passed to next name server in the hierarchy rather than the client.
 This process continues recursively until the complete path is resolved.
 Distributed
Implementation of Name Resolution Systems

 The principle of iterative name resolution.

 Distributed
Implementation of Name Resolution Systems

The principle of recursive name resolution.

 Distributed
Implementation of Name Resolution
Systems

 Recursive name resolution of <nl, vu, cs, ftp>.

 Name servers cache intermediate results for subsequent lookups.
 Distributed
Iterative Vs Recursive Resolution
Systems

The comparison between recursive and iterative name resolution with respect to communication costs.
 Distributed
Attribute Based Naming Systems

 Attribute-based naming name and lookup entities by means of their attributes

 Also known directory service (yellow page)
 Attribute-based naming
 Each entity is associated with a collection of attributes
 The naming system provides one or multiple entities that match a user’s description
 Problem
 Lookup operations can be extremely expensive,
 As it demands to match requested attribute values, against actual attribute values
 Done by inspecting all entities (in principle)
End of Chapter-5

41