P

R
E
P
A
R

UNIT 5
E
D

B
Y

S NAMING
U
L
A
V

N
E
P
A
L
P
R
E Name, Identifiers, & Addresses
P
A
R
 Names are used to share resources, to uniquely identify entities, to
E refer to locations, and more.
D

B
Y  An important issue with naming is that a name can be resolved to the
S entity it refers to.
U
L
A
V
 Name resolution thus allows a process to access the named entity.

N
E  To resolve names, it is necessary to implement a naming system.
P
A
L

2/16/2022 7:22 AM
P
R
E Name, Identifiers, & Addresses
P
A
R
 A name in distributed system is a string of bits or characters that is
E used to refer to an entity.
D

B
Y  An entity in a distributed system can be practically any resource such
S as hosts, printers, disks, files, processes, users, mailboxes, newsgroups,
U Web pages, graphical windows, messages, network connections, and so
L
A on.
V

N
E  To operate on an entity, it needs to be accessed from an access point
P
A
which is also called an address.
L

2/16/2022 7:22 AM
P
R
E Name, Identifiers, & Addresses
P
A
R
 For example, to print a file, we need to access it at an access point.
E
D
 An address is thus just a special kind of name: it refers to an access
B
Y point of an entity.
S
U
L  A name for an entity that is independent of an address is referred to
A
V
as location independent.
N
E  Identifier is a reference to an entity that is often unique and never
P
A reused.
L

2/16/2022 7:22 AM
P
R
E Name, Identifiers, & Addresses
P
A
R
 The properties of a true identifier are:
E  An identifier refers to at most one entity.
D
 Each entity is referred to by at most one identifier.
B
Y  An identifier always refers to the same entity

S
U  By using identifiers, it becomes much easier to unambiguously refer to
L
A an entity.
V

N
E  Addresses and identifiers are two important types of names that are
P
A
each used for very different purposes.
L
P
R
E Name, Identifiers, & Addresses
P
A
R
 In many computer systems, addresses and identifiers are represented in
E machine-readable form only, that is, in the form of bit strings.
D

B
Y  For example, an Ethernet address is essentially a random string of 48
S bits.
U
L
A
V
 Likewise, memory addresses are typically represented as 32-bit or 64-
bit strings.
N
E
P
A
L
P
R
E Name, Identifiers, & Addresses
P
A
R
 Naming system maintains a name-to-address binding to resolve name
E (or identifier) to address.
D

B
Y  The types of naming systems are as follows:
S  Flat Naming – unstructured naming
U
L
A  Structured Naming – resolves structured human-friendly names to
V
addresses.
N
E
P  Attribute-based Naming – resolves descriptive names to addresses.
A
L
P
R
Desirable Features of a
E
P Good Naming System
A
R
 A good naming system for a distributed system should have the
E features described below:
D
 Location Transparency
B
Y
 Location Independency
 Scalability
S
U  Uniform Naming Convention
L
A  Multiple user-defined Names for the same Object
V  Group Naming
N  Meaning Names
E
P  Performance
A
L
 Fault Tolerance
 Replication Transparency
P
R
E Structured Naming
P
A
R
 Flat names are good for machines, but are generally not very
E convenient for humans to use.
D

B
Y  As an alternative, naming systems generally support structured names
S that are composed from simple, human-readable names.
U
L
A
V
 Not only file naming, but also host naming on the Internet follows
this approach.
N
E
P
A
L
P
R
E Structured Naming
P
A
R
Name Spaces
E
D
 Names are commonly organized into what is called a name space.
B
Y

S  Name spaces for structured names can be represented as a labeled,

U
L directed graph with two types of nodes:
A
V  Leaf node
 Directory node
N
E
P
A
L
P
R
E Structured Naming
P
A Name Spaces
R
E
D
 Leaf Node
B  It represents a named entity and has the property that it has no outgoing
Y edges.
S  A leaf node generally stores information on the entity it is representing for
U example, its address – so that a client can access it.
L
A
V  Directory Node
N  It has a number of outgoing edges, each labelled with a name.
E  Each node in a naming graph is considered as another entity in a distributed
P
A
system, and in particular, has an associated identifier.
L  A directory node stores a table called directory table in which an outgoing edge
is represented as a pair (node identifier, edge label)
P
R
E Structured Naming
P
A
R
Name Spaces
E
D

B
Y

S
U
L
A
V

N
E
P
A
L
A general naming graph with a single root node
P
R
E Structured Naming
P
A Name Spaces
R
E
D  The naming graph has one root node namely 𝑛0, which has only outgoing and
no incoming edges.
B
Y
 Each path in a naming graph can be referred to by the sequence of labels
S corresponding to the edges in that path, such as
U 𝑁: [𝑙𝑎𝑏𝑒𝑙1, 𝑙𝑎𝑏𝑒𝑙2, … , 𝑙𝑎𝑏𝑒𝑙𝑛], where N refers to the first node in the
L path.
A
V
 Such a sequence is called a path name.
N
E
P  If the first node in a path name is the root of the naming graph, it is called an
A absolute path name.
L

 Otherwise, it is called a relative path name.

P
R
E Structured Naming
P
A Name Spaces
R
E
D  It is important to realize that names are always organized in a name space.

B
Y  A global name is a name that denotes the same entity, no matter where that name
is used in a system.
S
U
L  In other words, a global name is always interpreted with respect to the same
A directory node.
V

N  A local name is a name whose interpretation depends on where that name is being
E used.
P
A
L
 Put differently, a local name is essentially a relative name whose directory in
which it is contained is (implicitly) known.
P
R
E Structured Naming
P
A Name Spaces
R
E
D  A path name in file systems is generally represented as a single string in which the
labels are represented as a single string in which the labels are separated by a
B special separator character slash (“/”).
Y

S  This character is also used to indicate whether a path name is absolute.

U
L
A  For example, instead of using 𝑛0: [ℎ𝑜𝑚𝑒, 𝑠𝑡𝑒𝑒𝑛, 𝑚𝑏𝑜𝑥], that is, the actual
V path name is /home/steen/mbox.
N
E  Note also that when there are several paths that lead to the same node, that node
P can be represented with different path names.
A
L
 For example, node n5 can be referred to by /home/steen/keys (absolute
path) as well as /keys (relative path to /home/steen).
P
R
E Structured Naming
P
A
R
Name Spaces
E
D

B
Y

S
U
L
A
V

N
E
P
A
L
A general naming graph with a single root node
P
R
E Structured Naming
P
A
R
Name Resolution
E
D
 Name spaces offer a convenient mechanism for storing and retrieving
B
Y information about entities by means of names.
S
U
L  A path name should be possible to look up any information stored in
A
V
the node referred to by that name.
N
E  The process of looking up a name is called name resolution.
P
A
L
P
R
E Structured Naming
P
A Name Resolution
R
E
D  Let’s see how name resolution works, consider a path name such as
B
𝑁: < 𝑙𝑎𝑏𝑒𝑙1 , 𝑙𝑎𝑏𝑒𝑙2 , … , 𝑙𝑎𝑏𝑒𝑙𝑛 >.
Y
 Resolution of this name starts at node 𝑁 of the naming graph, where the
S
U name 𝑙𝑎𝑏𝑒𝑙1 is looked up in the directory table, and which returns the
L identifier of the node to which 𝑙𝑎𝑏𝑒𝑙1 refers.
A
V
 Resolution then continues at the identified node by looking up the name
N 𝑙𝑎𝑏𝑒𝑙2 in its directory table, and so on.
E
P
A  Assuming that the named path actually exists, resolution stops at the last
L node referred to by 𝑙𝑎𝑏𝑒𝑙𝑛 by returning the content of that node.
P
R
E Structured Naming
P
A Closure Mechanism
R
E
D  Name resolution can take place only if we know how and where to start.
B
Y  In our example, the starting node was given, and we assumed we had access
S
to its directory table.
U
L
 Knowing how and where to start name resolution is generally referred to as
A
V a closure mechanism.
N
E  Consider the string representation of a file name such as /ℎ𝑜𝑚𝑒/
P 𝑠𝑡𝑒𝑒𝑛/𝑚𝑏𝑜𝑥.
A
L
 To resolve this name, it is necessary to already have access to the directory
table of the root node of the appropriate naming graph.
P
R
E Structured Naming
P
A The Implementation of a Name Space
R
E
D  A name space forms the heart of a naming service, that is, a service that
B
allows users and processes to add, remove, and look up names.
Y
 A naming service is implemented by name servers.
S
U
L
 If a distributed system is restricted to a local-area network, it is often
A
V feasible to implement a naming service by means of only a single name
server.
N
E
P  However, in large-scale distributed systems with many entities, possibly
A spread across a large geographical area, it is necessary to distribute the
L implementation of a name space over multiple name servers.
P
R
E Structured Naming
P
A
R
Name Space Distribution
E
D

B
Y

S
U
L
A
V

N
E
P
A
L
An example partitioning of the DNS name space, including Internet-
accessible files, into three layers
P
R
E Structured Naming
P
A Implementation of Name Resolution
R
E  The distribution of a name space across multiple name servers affects the implementation of name
D resolution.
B
Y  Let us assume that name servers are not replicated and that no client-side caches are used.

S  Each client has access to a local name resolver, which is responsible for ensuring that the name
U resolution process is carried out.
L
A
 In reference to the earlier figure, assume the (absolute) path name
V 𝑟𝑜𝑜𝑡: [𝑛𝑙, 𝑣𝑢, 𝑐𝑠, 𝑓𝑡𝑝, 𝑝𝑢𝑏, 𝑔𝑙𝑜𝑏𝑒, 𝑖𝑛𝑑𝑒𝑥. ℎ𝑡𝑚𝑙] is to be resolved.
N
E  Using a URL notation,
path this name would correspond to
P ftp://ftp.cs.vu.nl/pub/globe/index.html.
A
L  There are now two ways to implement name resolution. i.e. iterative name resolution and recursive
name resolution.
P
R
E Structured Naming
P
A
R
Implementation of Name Resolution
E
D

B
Y

S
U
L
A
V

N
E
P
A
L
Principle of Iterative Name Resolution
P
R
E Structured Naming
P
A
R
Implementation of Name Resolution
E
D

B
Y

S
U
L
A
V

N
E
P
A
L
Principle of Recursive Name Resolution
P
R
E Structured Naming
P
A Example:The Domain Name System
R
E
D
 DNS is a global system for translating IP addresses to human-readable
B domain names.
Y

S  When a user tries to access a web address like “example.com”, their web
U
L browser or application performs a DNS query against a DNS server,
A supplying the hostname.
V

N  The DNS server takes the hostname and resolves it into a numeric IP
E
P address, which then web browser can connect to.
A
L
 Let’s discuss the concepts and ideas behind the DNS.
P
R
E Structured Naming
P
A
R
Example:The Domain Name System
E
D

B
Y

S
U
L
A
V

N
E
P
A
L
Purpose of DNS
P
R
E Structured Naming
P
A Example:The Domain Name System
R
E
D
 Earlier figure shows how TCP/IP uses a DNS client and a DNS server to
B map a name to an address.
Y

S  A user wants to use a file transfer client to access the corresponding file
U
L transfer server running on a remote host.
A
V
 The user knows only the file transfer server name such as example.com.
N
E
P  However, the TCP/IP suite needs the IP address of the file transfer server to
A
L make the connection.
P
R
E Structured Naming
P
A Example:The Domain Name System
R
E
D  The following six steps maps the host name to an IP address:
 The user passes the host name to the file transfer client.
B
Y
 The file transfer client passes the host name to the DNS client.
S
U  Each computer, after being booted, knows the address of one DNS server. The DNS
L client sends a message to a DNS server with a query that gives the file transfer server
A name using the known IP address of the DNS server.
V
 The DNS server responds with the IP address of the desired file transfer server.
N
E
P  The DNS server passes the IP address to the file transfer client.
A
L  The file transfer client now uses the received IP address to access the file transfer server.
P
R
E Structured Naming
P
A
R
Example:The Domain Name System
E
D

B
Y

S
U
L
A
V

N
E
P
A
L
Example of using DNS service
P
R
E Attribute – Based Naming
P
A
R
 Flat and structured names generally provide a unique and location-
E independent way of referring to entities.
D

B
Y  In many cases, it is much more convenient to name, and look up
S entities by means of their attributes.
U
L
A
V
 Each attribute says something about the entity.

N
E  Lookup operations can be extremely expensive as they require to
P
A match requested attribute values, against actual values.
L
P
R
E Attribute – Based Naming
P
A Directory Services
R
E
D
 It is crucial within a distributed environment to keep important
B information structured and quickly available.
Y

S  Data chaos does not only loom when using the Internet.
U
L
A
V  The search for important data in the company network can just as quickly
grow disproportionately.
N
E
P  “What is the extension number of colleague XY? What is his e-mail
A
L address?” This problem is solved by a directory service that keeps
information available in a well-structured, quickly searchable form.
P
R
E Attribute – Based Naming
P
A
R
Directory Services
E
D
 A service that stores collections of bindings between names and
B
Y
attributes and that looks up entries that match attribute-based
specifications is called a directory services.
S
U
L  Examples are Microsoft’s Active Directory Services, X500 and its
A
V cousin LDAP (Lightweight Directory Access Protocol), and so on.
N
E
 Directory services are sometimes called yellow pages services, and
P
A conventional name services are correspondingly called white pages
L services, in an analogy with the traditional types of telephone
directory.
P
R
E Attribute – Based Naming
P
A
R
Directory Services
E
D
 Directory services are also known as attribute-based name services.
B
Y

S  With directory services, entities have a set of associated attributes

U
L that can be used for searching.
A
V

N  In some cases, the choice of attributes can be relatively simple.

E
P
A
L  For example, in an e-mail system, messages can be tagged with
attributes for the sender, recipient, subject, and so on.
P
R
E Attribute – Based Naming
P
A Hierarchical Implementation: LDAP
R
E
D  In the ideal case, a central server keeps the data in a directory and distributes it to
all clients using a certain protocol.
B
Y
 The data is structured in a way that a wide range of applications can access them.
S
U
L  That way, it is not necessary for every single calendar tool and e-mail client to
A keep its own database – a central repository can be accessed instead.
V

N  This notably reduces the administration effort for the concerned information.
E
P
 The use of an open and standardized protocol like lightweight directory access
A
L
protocol (LDAP) ensures that as many different client applications as possible can
access such information.
P
R
E Attribute – Based Naming
P
A
R
Hierarchical Implementation: LDAP
E
D
 A directory in this context is a type of database optimized for quick
B
Y and effective reading and searching:
S  To make numerous (concurrent) reading accesses possible, the writing
U access is limited to a small number of updates by the administrator.
L
A
V
 Conventional databases are optimized for accepting the largest possible
N data volume in a short time.
E
P
A
L
P
R
E Attribute – Based Naming
P
A
R
Hierarchical Implementation: LDAP
E
D
 A directory in this context is a type of database optimized for quick
B
Y
and effective reading and searching:
 Because writing accesses can only be executed in a restricted fashion, a
S directory service is employed for administering mostly unchanging, static
U
L information.
A
V
 Data in a conventional database typically changes very often (dynamic
N data).
E
P
A  Phone numbers in a company directory do not change nearly as often as,
L
for instance, the figures administered in accounting.
P
R
E Attribute – Based Naming
P
A Hierarchical Implementation: LDAP
R
E
D  A directory in this context is a type of database optimized for quick and effective
reading and searching:
B  When static data is administered, updates of the existing data sets are very rare.
Y

S  When working with dynamic data, especially when data sets like bank accounts or
U accounting are concerned, the consistency of the data is of primary importance.
L
A  If an amount should be subtracted from one place to be added to another, both
V operations must happen concurrently, within a transaction, to ensure the balance over
the whose data stock.
N
E
 Databases support such transactions. Directories do not.
P
A
L  Short-term inconsistencies of the data are quite acceptable in directories.
P
R
E Attribute – Based Naming
P
A Structure of an LDAP Directory Tree
R
E
D  An LDAP directory has a tree structure.

B  All entries (called objects) of the directory have a defined position within this hierarchy.
Y

S  This hierarchy is called the directory information tree (DIT).

U
L
 The complete path to the desired entry, which unambiguously identifies it, is called
A
V
distinguished name (DN).

N  The single nodes along the path to this entry are called relative distinguished name
E (RDN).
P
A
L  Objects can generally be assigned to one of the possible two types – container & leaf.
P
R
E Attribute – Based Naming
P
A Structure of an LDAP Directory Tree
R
E
D  Container
B
 These objects can themselves contain other objects.
Y
 Such object classes are root (the root element of the directory tree, which does
S not really exist), c (country), ou (organizational unit), and dc (domain
U component).
L
A
V  This model is comparable to the directories (folders) in a file system.

N
E  Leaf
P  These objects sit at the end of a branch and have no subordinate objects.
A
L
 Examples are person, InetOrgPerson, or groupofNames.
P
R
E Attribute – Based Naming
P
A Decentralized Implementation
R
E
D  Notably with the advent of peer-to-peer systems, researchers have also been looking for
solutions for decentralized attribute-based naming systems.
B
Y  In particular, peer-to-peer systems are often used to store files.
S
U  Initially, files could not be searched – they could only be looked up by their key.
L
A
 However, having the possibility to search for a file based on descriptors can be extremely
V
convenient, where each descriptor is nothing but an (attribute, value) pair.
N
E  Obviously, querying every node in a peer-to-peer system to see if it contains a file
P matching one or more of such pairs is infeasible.
A
L
 What we need is a mapping of (attribute, value) pairs to index servers, which, in turn,
point to files matching those pairs.
P
R
E
P
A
R
E
D

B CASE STUDY
Y

S
U THE GLOBAL NAME SERVICE
L
A
and DNS
V

N
E
P
A
L