1 / 38

Naming - PowerPoint PPT Presentation

  • Uploaded on

Naming. Chapter 4. Nam es. A name is a string of bits or characters that is used to refer to an entity An entity can be practically anything In a distributed system: hosts, printers, disks, files, graphical windows users, mailboxes, newsgroups, Web pages,

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Naming' - mei

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript


Chapter 4

Nam es

  • A name is a string of bits or characters that is used to refer to an entity

  • An entity can be practically anything

  • In a distributed system:

    • hosts, printers, disks, files, graphical windows

    • users, mailboxes, newsgroups, Web pages,

    • messages, network connections and so on


  • Names:

  • Play an important role in all computer systems

  • Used to uniquelyidentify entities

  • Name resolution allows a process to access the named entity

  • In a distributed system:

  • The implementation of a naming system is itself often distributed across multiple machines

  • How this distribution is done plays a key role in the efficiency and scalability of the naming system

Desired properties of names
Desired Properties of Names

  • 􀂄 Addresses are not good candidates fornaming entities.

    − Change with system reorganization

    − Can have multiple addresses

  • 􀂄 Names should be stable.

  • 􀂄 Names should be location independent.

  • 􀂄 Names should be platform independent.

  • 􀂄 Names should be easily resolvable.

Name spaces 1
Name Spaces (1)

  • A leaf node represents a named entity

  • A directory node has a number of outgoing edges, each labeled with a name and stores a directory table in which an outgoing edge is represented

  • A node can be represented by differentpathnames(absolute / relative)

  • /home/steen/keys as well as /keys hard linksto node n5

Linking and mounting 1
Linking and Mounting (1)

  • Strongly related to name resolution is the use of aliases

  • An alias is another name for the same entity

  • /keys is a symbolic link to node n6. Instead of storing the address or state of that entity, n5 stores an absolute path name

Linking and mounting 2
Linking and Mounting (2)

  • Consider a collection of name spaces distributed across different machines

  • Each name space is implemented by a different server, each possibly running on separate machines

  • If we want to mount a foreign name space NS2 into a name space NS1, it may be necessary to communicate over a network

  • To mount a foreign name space in a distributed system requires at least the following information

    • The name of an access protocol

    • The name of the server

    • The name of the mounting point in the foreign name space

Linking and mounting 3
Linking and Mounting (3)


mount point

mounting point

  • nfs access protocol :// name space delimiter

  • name of the server home/steen mounting point

Linking and mounting 4
Linking and Mounting (4)

  • Organization of the DEC Global Name Service (GNS)Add a new root node and make the existing root nodes its children

Linking and mounting 5
Linking and Mounting (5)

  • A problem with GNS is that existing names need to be changed

  • The absolute path name/home/steen in NS1 has now changed into a reletive path name that is to be resolved starting in node n0and corresponds to the absolute path name /vu/home/steen

  • To solve these problems, names in GNS (implicitly) include a node identifier from where resolution should normally start

  • /home/steen/keys n0:/home/steen/keys

  • This expansion is hidden from users and different name spaces have different node identifiers

  • If thousands of name spaces are merged, this approach will eventually lead to performance problems

Implementation of a name space
Implementation of a Name Space

  • A name space forms the heart of a naming service

  • Naming service allows users and processes to add, remove, and look up names

  • Naming service is implemented by name servers

  • In local area, only a single name server is sufficient

  • In large-scale distributed systems with many (billions) entities, possibly spread across a large geographical area, it is necessary to distribute the implementation of a name space over multiple name servers

Name space distribution 1
Name Space Distribution (1)

logical layers

  • An example partitioning of the DNS name space, including Internet-accessible files, into three layers

Name space distribution 2
Name Space Distribution (2)

  • A comparison between name servers for implementing nodes from a large-scale name space partitioned into a global layer, as an administrational layer, and a managerial layer

Implementation of name resolution 1
Implementation of Name Resolution (1)

  • The principle of iterative name resolution for


Implementation of name resolution 2
Implementation of Name Resolution (2)

  • The principle of recursive name resolutionfor


Implementation of name resolution 3
Implementation of Name Resolution (3)

  • Recursive name resolution of <nl, vu, cs, ftp>

  • Name servers cache intermediate results for subsequent lookups

Implementation of name resolution 4
Implementation of Name Resolution (4)

  • The comparison between recursive and iterative name resolution with respect to communication costs

Locating mobile entities
Locating Mobile Entities

  • The naming services discussed so far, are primarily used for naming entities that have a fix location

  • Traditional naming systems are not well suited for supporting mobile entities

  • Consider updating the address of, because the ftp server is to be moved to a different machine, as long as the server is moved to a machine within the domain, the update can be done efficiently

  • If were to move a machine named, which lies in a completely different domain, changing all links to it become invalid

  • Solution is to record the address (or name) of the new machine in the DNS database for

Naming versus locating entities
Naming versus Locating Entities

  • Direct, single level mapping between names and addresses.

  • T-level mapping using identities.

Simple solutions for locating entities
Simple Solutions for Locating Entities

  • Forwarding Pointers:Each time an entity moves, it

  • leaves behind a pointer telling where it has gone to

  • Broadcasting:Simply broadcast the ID, requesting the entity to return its current address

  • Drawbacks:

    • Can never scale beyond local-area networks

    • Requires all processes to listen to incoming location requests

Forwarding pointers 1
Forwarding Pointers (1)

The principle of forwarding pointers using(proxy, skeleton)pairs


  • 1) a chain can become so long

  • 2) vulnerability to broken links

  • 3) intermediate locations have to maintain their part of the chain

Forwarding pointers 2
Forwarding Pointers (2)

  • Redirecting a forwarding pointer, by storing a shortcut in a proxy

Home based approaches 1
Home-Based Approaches (1)

  • Let a homekeep track of where the entity is:

    • An entity’s home addressis registered at a naming service

    • The home registers the foreign addressof the entity

    • Clients always contact the home first, then continues with the foreign location

Home based approaches 2
Home-Based Approaches (2)

  • Problems with home-based approaches:

  • Increase a communication latency

  • The home address has to be supportedas long as theentity lives

  • The home address is fixed, which means an unnecessary burden when the entity permanently moves to another location

  • Poor geographical scalability (the entity may be next to the client)

Question: How can we solve the permanent moveproblem?

Hierarchical approaches 1
Hierarchical Approaches (1)

corresponds to a local area network

  • Hierarchical organization of a location service into domains

  • Each having an associated directory node that keeps track of the entities in that domain

Hierarchical approaches 2
Hierarchical Approaches (2)

  • An example of storing information of a replicated entity having two addresses in different leaf domains

Hierarchical approaches 3
Hierarchical Approaches (3)

  • Looking up a location in a hierarchically organized location service.

Hierarchical approaches 4
Hierarchical Approaches (4)

  • An insert request is forwarded to the first node that knows about entity E

  • A chain of forwarding pointers to the leaf node is created

Pointer caches 1
Pointer Caches (1)

  • Consider a mobile entity Emoves regularly within a domain D

  • It is effective to cache a reference to the directory node D

Pointer caches 2
Pointer Caches (2)

Question:When to invalidate a cache entry?

  • A cache entryneeds to be invalidated because it returns a nonlocal address, while such an address is available

Scalability issues 1
Scalability Issues (1)

  • The root node is required to store a location record for each entity and to process requests for each entity

  • Suppose the size of each location record is 1 KB, required storage capacity for a billion entities is 1 terabyte

  • The real problem is the root may be required to handle so many lookup and update requests that it will become bottleneck

  • The solution is to partition the root node and other high-level directory nodes into subnodes

  • Suppose partition root node into 100 subnodes, the question is where to physically place each subnode in the network

Scalability issues 2
Scalability Issues (2)

  • The scalability issues related to uniformly placing subnodes of a partitioned root node across the network covered by a location service

The problem of unreferenced objects
The Problem of Unreferenced Objects

  • An example of a graph representing objects containing references to each other

Simple reference counting 1
Simple Reference Counting (1)

  • Each time a reference to an object is created, a reference counter for that object is incremented

  • When a reference is removed, the reference counter is decremented

  • The problem of maintaining a proper reference count in the presence of unreliable communication

Simple reference counting 2
Simple Reference Counting (2)

  • Copying a reference to another process and incrementing the counter too late

  • A solution

Tracing in groups 1
Tracing in Groups (1)

  • Processes in a large distributed system are organized into groups

  • Garbage-collection takes place within groups through a combination of mark-and-sweepand reference counting

  • Initial marking; only skeletons are soft marked

Tracing in groups 2
Tracing in Groups (2)

  • Intraprocess (local) propagation of marks from skeletons to proxies

Tracing in groups 3
Tracing in Groups (3)

  • Interprocess propagation of marks from proxies to skeletons