name enti n locatn

8/7/2019 name enti n locatn

1/38

Distributed SystemsPrinciples and Paradigms

Chapter 04(version 15th May 2006)

Maarten van Steen

Vrije Universiteit Amsterdam, Faculty of Science

Dept. Mathematics and Computer Science

Room R4.20. Tel: (020) 444 7784

E-mail:[email protected], URL: www.cs.vu.nl/ steen/

01 Introduction02 Communication

03 Processes04 Naming05 Synchronization06 Consistency and Replication07 Fault Tolerance08 Security09 Distributed Object-Based Systems10 Distributed File Systems

11 Distributed Document-Based Systems12 Distributed Coordination-Based Systems

00 1 /


2/38

Naming Entities

Names, identifiers, and addresses Name resolution

Name space implementation

04 1 Naming/4.1 Naming Entities


3/38

Naming

Essence: Names are used to denote entities in a dis-

tributed system. To operate on an entity, we need to

access it at an access point. Access points are enti-

ties that are named by means of an address.

Note: A location-independent name for an entity

E, is independent from the addresses of the accesspoints offered by E.



4/38

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 (pro-

hibits reusing an identifier)

Observation: An identifier need not necessarily be apure name, i.e., it may have content.

Question: Can the content of an identifier ever change?



5/38

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.

elke

.twmrc mbox

steen

home keys

"/home/steen/mbox"

"/keys"

"/home/steen/keys"

Data stored in n1

Directory node

Leaf node

n2: "elke"n3: "max"n4: "steen"

max

keys

n1

n2

n5

n0

n3 n4

Note: A directory node contains a (directory) table of

(edge label, node identifier) pairs.



6/38

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 entitys location Nicknames ...

Observation: Directory nodes can also have attributes,

besides just storing a directory table with (edge label,

node identifier) pairs.



7/38

Name Resolution

Problem: To resolve a name we need a directory

node. How do we actually find that (initial) node?

Closure mechanism: The mechanism to select the

implicit context from which to start name resolution:

: start at a DNS name server " $ & ) & & $ 5 " 6 : start at the local NFS file server

(possible recursive search) 8 8 @ B D 8 F F F H H P F : dial a phone number B @ 8 @ H D F P : route to the VUs Web server

Question: Why are closure mechanisms always im-

plicit?

Observation: A closure mechanism may also deter-

mine how name resolution should proceed



8/38

Name Linking (1/2)

Hard link: What we have described so far as a path

name: a name that is resolved by following a specific

path in a naming graph from one node to another.

Soft link: Allow a node O to contain a name of an-

other node:

First resolve Os name (leading to O) Read the content of O, yielding V $ &

Name resolution continues with V $ &

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

V $ &



9/38

Name Linking (2/2)

.twmrc

"/home/steen/keys"

"/keys"n1

n2

n5

n0

n3

n6

mbox "/keys"

Data stored in n6n4

elke steen

home keys

Data stored in n1

Directory node

Leaf node

n2: "elke"n3: "max"n4: "steen"

max

keys

Observation: NodeX Y

has only one name



10/38

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 con-

catenated (URLs).

` a c e f f ` a c p q s p t v p x y f c v f s a x f

` a c

Name of protocol used to talk with servere f f

Name space delimiter` a c p q s p t v p x y

Name of a node representing an FTP server,and containing the IP address of that server

f

Name space delimiterc v f s a x f

Name of a (context) node in the name spacerooted at the context node mapped to the FTPserver



11/38


Solution 2: Introduce nodes that contain the name of

a node in a foreign name space, along with the infor-mation how to select the initial context in that foreign

name space (Jade).

Name server Name server for foreign name space

Reference to foreign name spaceNetwork

Machine A Machine B

O

S

vu

remote

keys

"nfs://flits.cs.vu.nl//home/steen"

mbox

s

teen

home

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.



12/38


Solution 3: Use only full pathnames, in which the

starting context is explicitly identified, and merge by

adding a new root node (DECs Global Name Space).

elke

.twmrc

steen

home keys

n0

max

keysmbox

mbox

m0

m0 homen0 vu

"n0:/home/steen/keys"

vuhome

NS1 NS2

"m0:/mbox"

Note: In principle, you alwayshave to start in the new

root



13/38

Name Space Implementation (1/2)

Basic issue: Distribute the name resolution process

as well as name space management across multiplemachines, by distributing nodes of the naming graph.

Consider a hierarchical naming graph and distinguish

three levels:

Global level: Consists of the high-level directory nodes.

Main aspect is that these directory nodes have to

be jointly managed by different administrations

Administrational level: Contains mid-level directory

nodes that can be grouped in such a way thateach group can be assigned to a separate ad-

ministration.

Managerial level: Consists of low-level directory nodes

within a single administration. Main issue is ef-

fectively mapping directory nodes to local name

servers.



14/38


15/38

Iterative Name Resolution

& " & j l o V $ & B o o V $ & is sent toz

& & 8 re-

sponsible for j l

z

& & 8 resolves & " & j l o V $ & B } j l B , return-

ing the identification (address) of z & & B , which

stores j l B .

Client sends & " & j l B o V $ & D o o V $ & toz

& & B

etc.

Client'snameresolver

Rootname server

Name servernl node

Name servervu node

Name servercs node

1.

2. #,

3.

4. #,

5.

6. #,

ftp

cs

vu

nl

Nodes are

managed byt

he same server

7.

8. #

#



16/38

Recursive Name Resolution

& " & j l o V $ & B o o V $ &

is sent toz

& & 8

re-sponsible for j l

z

& & 8 resolves & " & j l o V $ & B } j l B , and sends & " & j l B o V $ & D o o V $ & to

z

& & B , which storesj l B .

z

& & 8 waits for the result fromz

& & B , and re-

turns it to the client.

Client'snameresolver

Rootname server

Name servernl node

Name serverv

u node

Name servercs node

1.

2.

7. #3.

6. #4.

5. #

#

8. #



17/38


18/38

Scalability Issues (1/2)

Size scalability: We need to ensure that servers can

handle a large number of requests per time unit

high-level servers are in big trouble.

Solution: Assume (at least at global and administra-

tional level) that content of nodes hardly ever changes.

In that case, we can apply extensive replication bymapping nodes to multiple servers, and start name

resolution at the nearest server.

Observation: An important attribute of many nodes

is the address where the represented entity can be

contacted. Replicating nodes makes large-scale tra-

ditional name servers unsuitable for locating mobile

entities.



19/38

Scalability Issues (2/2)

Geographical scalability: We need to ensure that

the name resolution process scales across large geo-

graphical distances.

Problem: By mapping nodes to servers that may, in

principle, be located anywhere, we introduce an im-

plicit location dependency in our naming scheme.

Solution: No general one available yet.



20/38

Locating Mobile Entities

Naming versus locating objects Simple solutions

Home-based approaches

Hierarchical approaches

04 19 Naming/4.2 Locating Mobile Entities


21/38

Naming & Locating Objects (1/2)

Location service: Solely aimed at providing the ad-dresses of the current locations of entities.

Assumption: Entities are mobile, so that their cur-

rent address may change frequently.

Naming service: Aimed at providing the content of

nodes in a name space, given a (compound) name.

Content consists of different (attribute,value) pairs.

Assumption: Node contents at global and adminis-

trational level is relatively stable for scalability rea-

sons.

Observation: If a traditional naming service is used

to locate entities, we also have to assume that node

contents at the managerial level is stable, as we can

use only names as identifiers (think of Web pages).



22/38


23/38

Simple Solutionsfor Locating Entities

Broadcasting: Simply broadcast the ID, requestingthe entity to return its current address.

Can never scale beyond local-area networks (think

of ARP/RARP) Requires all processes to listen to incoming loca-

tion requests

Forwarding pointers: Each time an entity moves, it

leaves behind a pointer telling where it has gone to.

Dereferencing can be made entirely transparent

to clients by simply following the chain of pointers Update a clients reference as soon as present

location has been found Geographical scalability problems:

Long chains are not fault tolerant

Increased network latency at dereferencing

Essential to have separate chain reduction mech-

anisms



24/38

Home-Based Approaches (1/2)

Single-tiered scheme: Let a home keep track of where

the entity is: An entitys home address is registered at a nam-

ing service The home registers the foreign address of the

entity

Clients always contact the home first, and thencontinues with the foreign location

Host's present location

C

lient'slocation

1. Send packet to host at its home

2

. Return addresso

f current location

3

. Tu

nnel packet toc

urrent location

4. Send successive packetst

o current location

Host's homelocation



25/38

Home-Based Approaches (2/2)

Two-tiered scheme: Keep track of visiting entities:

Check local visitor register first Fall back to home location if local lookup fails

Problems with home-based approaches:

The home address has to be supported as long

as the entity lives. The home address is fixed, which means an un-

necessary burden when the entity permanently

moves to another location

Poor geographical scalability (the entity may benext to the client)

Question: How can we solve the permanent move

problem?



26/38

Hierarchical Location Services(HLS)

Basic idea: Build a large-scale search tree for which

the underlying network is divided into hierarchical do-

mains. Each domain is represented by a separate di-

rectory node.

A leaf domain, contained in S

Directory nodedir(S) of domain S

A

subdomain Sof top-level domain T(S is contained in T)

Top-leveldomain T

The root directorynode dir(T)



27/38

HLS: Tree Organization

The address of an entity is stored in a leaf node,or in an intermediate node

Intermediate nodes contain a pointer to a child if

and only if the subtree rooted at the child stores

an address of the entity

The root knows about all entities

Domain D2Domain D1

M

Field with no data

Location recordwith only one field,containing an address

Field for domaindom(N) withpointer to N

Location recordfor E at node M

N



28/38

HLS: Lookup Operation

Basic principles:

Start lookup at local leaf node If node knows about the entity, follow downward

pointer, otherwise go one level up Upward lookup always stops at root

Domain D

M

Node has norecord for E, sot

hat request isforwarded toparent

Look-uprequest

Node knowsabout E, so requestis forwarded to child



29/38

HLS: Insert Operation



30/38

HLS: Record Placement

Observation: If an entity E moves regularly between

leaf domains D1 and D2, it may be more efficient tostore Es contact record at the least common ancestor

of j l D1 and j l D2

.

Lookup operations from either D1 or D2 are on

average cheaper Update operations (i.e., changing the current ad-

dress) can be done directly at

Note: assuming that Egenerally stays in j " $

,

it does make sense to cache a pointer to

Domain D

E moves regularly betweent

he two subdomainsCached pointerst

o node dir(D)



31/38

HLS: Scalability Issues

Size scalability: Again, we have a problem of over-

loading higher-level nodes:

Only solution is to partition a node into a number

of subnodes and evenly assign entities to sub-

nodes Naive partitioning may introduce a node manage-

ment problem, as a subnode may have to know

how its parent and children are partitioned.

Geographical scalability: We have to ensure that

lookup operations generally proceed monotonically in

the direction of where well find an address:

If entityEgenerally resides in California, we should

not let a root subnode located in France store Es

contact record. Unfortunately, subnode placement is not that easy,

and only a few tentative solutions are known



32/38

Reclaiming References

Reference counting Reference listing

Scalability issues

04 31 Naming/4.3 Reclaiming References


33/38

Unreferenced Objects: Problem

Assumption: Objects may exist only if it is known that

they can be contacted:

Each object should be named Each object can be located A reference can be resolved to clientobject com-

munication

Problem: Removing unreferenced objects:

How do we know when an object is no longer ref-

erenced (think of cyclic references)?

Who is responsible for (deciding on) removing anobject?



34/38

Reference Counting (1/2)

Principle: Each time a client creates (removes) a ref-

erence to an object O, a reference counter local to Ois incremented (decremented)

Problem 1: Dealing with lost (and duplicated) mes-

sages: An l & $ & ) is lost so that the object may be pre-

maturely removed A j & & $ & ) is lost so that the object is never re-

moved An ACK is lost, so that the increment/decrement

is resent.

Solution: Keep track of duplicate requests.

ACK is lost

+1

+1

ACK

A

CK

1

2

3

4

Skeleton (maintains reference counter)

Proxy p is now counted twice

Process P

Proxy p

Object O



35/38

Reference Counting (2/2)

Problem 2: Dealing with duplicated references client

P1 tells client P2 about object O: Client P2 creates a reference to O, but derefer-

encing (communicating with O) may take a long

time If the last reference known toO is removed before

P2 talks to O, the object is removed prematurely

Solution 1: Ensure that P2 talks to O on time:

Let P1 tell O it will pass a reference to P2 Let O contact P2 immediately A reference may never be removed before O has

acked that reference to the holder

P1 P1

P2 P2

O

O

P1 sendsreference to P2

P1 sends

reference to P2

P1 deletes itsreference to O

P1 deletes itsreference to O

-1 -1

+1ACK

P2 informs O it

has a reference

O

acks it knows

a

bout P2's reference

T

ime T

ime

O

has beenremoved

P1 tells O that it willpass a reference to P2

(a) (b)



36/38

Weighted Reference Counting

Solution 2: Avoid increment and decrement messages:

Let O allow a maximum M of references Client P1 creates reference grant it M 2 credit Client P1 tells P2 about O, it passes half of its credit

grant to P2 Pass current credit grant back to O upon refer-

ence deletion

SkeletonObject O

128128

128

12864

64

64

32

32

T

otal weight

Partial weight

Process P

Process P1

Process P2

Proxy

Partialw

eightof proxy

Partial weight atskeleton is halved

P2 gets halfof the weightof proxy at P1 Total and partial

weight at skeletonremain the same

(a) (b)

(c)

P1 passesreference to P2



37/38

Reference Listing

Observation: We can avoid many problems if we can

tolerate message loss and duplication

Reference listing: Let an object keep a list of its

clients:

Increment operation is replaced by an (idempo-

tent)l & )

Decrement operation is replaced by an (idempo-

tent) & $ " &

There are still some problems to be solved:

Passing references: client B has to be listed at O

before last reference at O is removed (or keep a

chain of references)

Client crashes: we need to remove outdated regis-

trations (e.g., by combining reference listing with

leases)



38/38

Leases

Observation: If we cannot be exact in the presence

of communication failures, we will have to tolerate some

mistakes

Essential issue: We need to avoid that object refer-

ences are never reclaimed

Solution: Hand out a lease on each new reference:

The object promises not to decrement the refer-

ence count for a specified time Leases need to be refreshed (by object or client)

Observations:

Refreshing may fail in the face of message loss Refreshing can tolerate message duplication Does not solve problems related to cyclic refer-

ences


name enti n locatn

Documents