Naming
This presentation is the property of its rightful owner.
Sponsored Links
1 / 38

Naming PowerPoint PPT Presentation


  • 87 Views
  • Uploaded on
  • Presentation posted in: General

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,

Download Presentation

Naming

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


Naming

Naming

Chapter 4


Nam es

Names

  • 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


Naming1

Naming

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

/remote/vu/mbox

mount point

mounting point

  • nfs access protocol:// name space delimiter

  • flits.cs.vu.nl name of the serverhome/steenmounting 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/keysn0:/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

  • ftp://ftp.cs.vu.nl/pub/globe/index.txt


Implementation of name resolution 2

Implementation of Name Resolution (2)

  • The principle of recursive name resolutionfor

  • ftp://ftp.cs.vu.nl/pub/globe/index.txt


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 ftp.cs.iku.edu.tr, because the ftp server is to be moved to a different machine, as long as the server is moved to a machine within the cs.iku.edu.tr domain, the update can be done efficiently

  • If ftp.cs.iku.edu.tr were to move a machine named ftp.cs.vu.nl, 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 cs.iku.edu.tr


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

Drawbacks:

  • 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


  • Login