naming n.
Skip this Video
Download Presentation

Loading in 2 Seconds...

play fullscreen
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

Download Now 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