A Name Refers to an Object. Allows Passing of Reference to Objects

Naming Framework

■ A name refers to an object. Allows passing of reference to objects.

Example of names

Register R2

Memory 0xforgetfull

Hostsomeone.com

Useryourguess

Email

File /usr/yourguess/myprog.txt

URL

3 key elements control the naming model.

■ Name space

Alphabet of symbols and syntax generating names

■ Name mapping

e.g.

■ Universe of values: List of values comprising an object. e.g. resource vector of object are the set of resources .

Other issues of importance:

■ Location transparency: Object name should not reveal the physical location of the object.

■ Location independency: Object name should not be determined by object location. Objects are often migrated from nodes to nodes for security, performance, reliability

and availability.

■ Scalability: Distributed systems are open, and therefore should be scalable.

■ Uniform naming conventions: Many systems use different naming conventions for different objects. e.g. file names structure differs from user name structures or process names. A good naming system should use the same naming convention.

■ Multiple user-defined names for the same object: For a shared object, it’s desirable that users use their own naming convention. If a user does change or delete her name for the object, it shouldn’t impact other users.

■ Group naming:

■ Meaningful names:

■ Performance: Mapping like attributes(object) (location, density) requires a lot of message passing. This impacts upon system performance.

■ Fault-tolerance: A Nameserver system should be fault-tolerant to some extent.

■ Replication transparency: A naming system should support use of multiple copies of the same object in a transparent manner. User should not be aware that multiple copies exist.

■ Locating nearest replica: Given multiple copies of an object, the naming system should point to the nearest object. Not this:

Client should be able to get to object 1 instead of object i.

■ Locating all replicas: For systematic updating in case of possible failures.

If nearest object is not available (due to link failure, etc.), another object j may be chosen by the naming system.

■ Name Space. Must be unique. Typical design features.

♦ Flat Name Space (FNS): Names are character strings.Names here are called primitive, or simple or flat names. Useful for small object sets.

♦ Partitioned Name Space (PNS): For a large set of objects, the space is partitioned into disjoint classes each of which is called a domain. A domain may be a FNS or another PNS. Object names in PNS are not simple but compound. e.g. a/b/c

A Hierarchical Name Space is a PNS with each domain being a PNS.

■ Name Server (NS): Name Space is managed by Name Servers. The NS that store the information of an object are called Authoritative Name Servers (ANS). Name service must be able to decide the attributes of ANS for every object (where is it located, etc.)

A NS is a process that

* provides location of an object

* maintain information about the names objects

* allows systematic updates on its objects.

.

A PNS is easier to manage efficiently by a NS. Normally, in a hierarchical name space, one may have one ANS for each of the root domain. This would provide the name service to a client.

Client in may contact its for service about an object. If the object is not known here, the would be contacted for resolution.

Name Agent: This object provides the location and the attributes of the NS to a client. NA acts between a client and a NS.

● one-to-one mapping

● one-to-many mapping or many-to-one mapping

● context sensitive resolution

e.g. Context-sensitive resolution. A large disaster area with rescue workers wearing helmets with attached cameras. The cameras are named by their locations. To view any particular location, we can now specify the camera name.

● Context sensitive names may change over time.

● Scalability issue

● Persistent name matching : INS (International

Naming Service) has to handle frequent name

updates in a mobile environment.

■ Stable binding

● names are never reused

● values could have only one names

● facilitates reverse lookup support. e.g.

: looking for nodes that

have resources with attributes

■ Reverse lookup support

Name lookup styles:

● table lookup, one table per context

● recursive lookup: DNS server can’t resolve a lookup. It can send it to higher up DNS server for a resolution. e.g. path + file_name, hostname + domain,

● multiple lookup: for a query