Naming

1
Naming

• Chapter 4

2
Why Naming?

• Names are needed to
• Identify entities
• Share resources
• Refer to locations, etc.
• It is necessary to resolve names
• What does human-friendly name correspond to
• Need a naming system
• In distributed systems, naming system itself is
  often distributed

3
Outline of Chapter

• General naming issues
• Human-friendly names
• Naming and mobility
• Such as mobile telephony
• Unreferenced objects
• How to remove unused names

4
Names, Identifiers, Addresses

• A name is a string of bits that refers to an
  entity
• An entity is practically anything
• Entities can be operated on
• To operate on entity, must know an access point
• Access point is just another entity!
• Name of an access pt is an address

5
Names, Identifiers, Addresses

• Example
• Telephone is an access point
• Telephone number is address
• Distributed systems example
• Server is an access point
• IP address/port number is address
• Mobility creates special problems

6
Names, Identifiers, Addresses

• Address is a special kind of name
• For an access point
• Access point associated with an entity
• Why not use address as entity name?
• Entities may change access points
• For example, IP address vs MAC address
• Entity may offer more than one access point
• For example, Web service with multiple servers
• An entity name that is independent of its address
  is location independent

7
Names, Identifiers, Addresses

• An identifier is a special type of name
• Identifier refers to at most one entity
• Entity referred to by at most one identifier
• Identifier is never reused
• That is, identifiers are unambiguous
• Mark Stamp is not an identifier
• Telephone number is not an identifier
• Examples of identifiers?

8
Names, Identifiers, Addresses

• Human-friendly names?
• File names
• www.google.com
• Other?
• Human unfriendly names?
• Memory locations
• Other?

9
Name Spaces

• Organization of names in distributed system is a
  name space
• Represented as a labeled directed graph
• Usually restricted to directed acyclic graphs
• Leaf node is a named entity
• Has no outgoing edge
• Leaf node stores address and/or state
• Directory node has a table
• Can have many outgoing edges
• Root node has no incoming edges
• Usually only one

10
Name Spaces

• Naming graph with single root node n0
• Complete path is a path name
• Begins with n0, then its an absolute path
• Otherwise, a relative path

11
Name Spaces

• Names organized in a name space
• Implies that a name is defined relative to a
  directory node
• Global name denotes same entity no matter where
  the name is used
• Local name depends on where its used
• In other words, a local name is a relative name
  whose directory is known

12
Name Spaces

• Example UNIX file system
• A single root node
• File directory is a directory node
• File is a leaf node

13
Name Resolution

• Given path name, must be able to access the
  specified node
• This process is name resolution
• How does this work?
• Short answer traverse the directed graph
• Long answer see the book
• But, must know where to start
• For example, how to resolve 7127552339 ?
• First, must know its a phone number
• I.e., must know root node of appropriate graph

14
Linking and Mounting

• An alias is another name for something
• Can have multiple paths to same node, or
• A symbolic link in naming graph (as above)

15
Linking and Mounting

• Combine different name spaces
• Need directory node in other name space
• Node storing node identifier of foreign name
  space is mount point
• Directory node in foreign name space is mounting
  point (usually root node)
• Important in distributed systems!

16
Linking and Mounting

• In distributed system
• To mount foreign name space, need
• Name of access protocol
• Name of server
• Name of mounting point
• Name resolution required

17
Linking and Mounting

• Consider Network File System (NFS)
• Distributed file system
• Discussed in detail in chapter 10
• Access a file by NFS URL
• For example, nfs//flits.cs.vu.nl//home/steen
• File (directory) /home/steen
• On server flits.cs.vu.nl
• Accessed using NFS protocol
• Access protocol, server, mounting point?

18
Linking and Mounting

• Consider (machine A) /remote/vu/mbox
• On A, nfs//flits.cs.vu.nl//home/steen
• Then to machine B

19
Linking and Mounting

• DEC Global Name Service (GNS)
• Insert a new root node
• Existing names change
• Can avoid changing names
• See book

20
Name Space Implementation

• Naming service
• To add, remove, lookup names
• Implemented on name server(s)
• In distributed system, naming service itself may
  be distributed
• Name space is heart of naming service
• Name space distribution (organization)
• Name resolution

21
Name Space Distribution

• Usually organized hierarchically
• Assume one root
• Three logical layers
• Global layer ? root and nearby (very stable)
• Administrational layer ? directory nodes in one
  organization (relatively stable)
• Managerial layer ? typically, hosts in one
  network (not stable)
• For example, DNS

22
Name Space Distribution

• DNS name space in three layers
• Subtle performance issues
• Different requirements at each layer

23
Name Space Distribution
Managerial
Administrational
Global
Item
Department
Organization
Worldwide
Geographical scale of network
Vast numbers
Many
Few
Total number of nodes
Immediate
Milliseconds
Seconds
Responsiveness to lookups
Immediate
Immediate
Lazy
Update propagation
None
None or few
Many
Number of replicas
Sometimes
Yes
Yes
Is client-side caching applied?

• Comparison of name servers

24
Name Resolution

• Two approaches
• Iterative name resolution
• Server sends result back to client
• More work for client
• Recursive name resolution
• Server contacts next name server
• More work for servers

25
Iterative Name Resolution

• Caching limited to client

26
Recursive Name Resolution

• Caching is more effective (next slide)
• More efficient communication (slide after next)

27
Name Resolution

• Recursive name resolution of
• Name servers cache intermediate results

28
Name Resolution
Netherlands
San Jose

• Recursive versus iterative name resolution
• Comparing communication costs

29
Examples

• DNS ? traditional naming service
• Hierarchical, rooted tree
• Like a white pages service for Internet
• You should be familiar with this
• Read it!
• X.500 ? directory service
• Find an entity that fits a description
• Like a yellow pages service

30
DNS Name Space

• Hierarchical, rooted tree
• Each node has 1 incoming edge (except the root)
• Incoming edge used as name of node
• A subtree is a domain
• Path name is a domain name
• Can be relative or absolute
• Node contains resource records

31
DNS Name Space

• Most important types of resource records

32
DNS Implementation

• DNS includes
• Global layer
• Administrational layer
• Managerial layer not formally in DNS
• Read the details

33
DNS Implementation

• Excerpt from DNS database for the zone cs.vu.nl

34
DNS Implementation

• Description for vu.nl domain
• This domain contains cs.vu.nl domain

35
X.500 Name Space

• Each record consists of
• (attribute, value) pairs
• Attribute can have multiple values
• Directory Information Base (DIB)
• All entries in X.500 directory service
• Each attribute is a Relative Distinguished Name
  (RDN)
• Complete record is globally unique
• So it can be looked up

36
X.500 Name Space

• Example of X.500 directory entry
• Unique name Country, Organization,
  OrganizationalUnit
• /CNL/OVrije Universiteit/OUMath. Comp. Sc.
• Analogous to DNS nl.vu.cs

37
X.500 Name Space

• Globally unique names form hierarchy
• Directory Information Tree (DIT)
• The naming graph in X.500
• Node can act as directory
• More than one child
• See next slide

38
X.500 Name Space

• Part of directory information tree
• N acts as directory
• and as a node

39
X.500 Name Space

• Two entries with Host_Name as RDN

40
X.500 Implementation

• Like DNS
• But more lookup operations to search DIB
• For example, can search for all main servers at
  Vrije Universiteit
• See example in book
• But, need to access many leaf nodes
• Leaf nodes might be distributed
• This could be expensive!

41
X.500 in the Real World

• X.500
• Uses Directory Access Protocol (DAP)
• Runs over OSI
• Therefore, it is heavyweight
• What if you like X.500
• but need to use it in the real world?
• Need something lightweight

42
LDAP

• Lightweight Directory Access Protocol
• Application level protocol
• Implemented on top of TCP
• Lookup, update, passed as strings
• No separate encoding required
• LDAP is defacto standard
• We used LDAP at my startup company

43
Mobility

• What is different in mobile case?
• Names change frequently
• Why is this an issue?
• Consider DNS
• Global layer and admin. layers assume names
  change infrequently
• So replication and caching are used
• For mobile, something else is needed
• But what?

44
Mobility

• Consider DNS
• ftp.cs.vu.nl
• Local cache probably has cs.vu.nl
• One request to find desired address
• Now spse ftp server moves
• If it stays in cs.vu.nl, only local changes
• What if it moves to ftp.cs.unisa.edu.au ?

45
Mobility

• Spse ftp.cs.vu.nl moves to ftp.cs.unisa.edu.au
• What to do?
• Forget about cs.vu.nl
• Users wont be happy
• Record new address under cs.vu.nl
• If it moves locally, update is not local
• Turn cs.vu.nl into a symbolic link
• In effect, 2 lookups
• But it gets no worse if it moves again
• Either way, name can never change

46
Mobility

• Better idea
• Give up on DNS-like approach
• Add an intermediate step
• Assign non-human-friendly identifier
• Then
• Name service converts human-friendly name into
  identifier
• Location service converts identifier to current
  address

47
Naming versus Locating

• DNS-like mapping between name and address
• Two-level mapping using identifiers

48
Mobility

• But this begs the question
• How to build location service?
• Simple solutions
• Broadcasting and multicasting
• Forwarding pointers
• Complicated (?) solutions
• Home-based approaches
• Hierarchical approaches

49
Broadcasting and Multicasting

• Spse mobility restricted to LAN
• Broadcasting is efficient on LAN
• Use ARP to locate entity
• Does not scale well
• Can do similar thing at network layer
• Use multicasting
• Mobile computer gets dynamic IP address and joins
  multicast group
• Multicast group acts as location service

50
Forwarding Pointers

• Another simple approach
• Forwarding pointers
• When moving from A to B, leave a pointer at A to
  new location B
• Naming service still points to A
• Simple, yes, but
• Chain might get long
• Every link in chain must be maintained

51
Forwarding Pointers

• Forwarding pointers as (proxy, skeleton)

52
Forwarding Pointers

• Redirecting a forwarding pointer
• To shortcut a chain
• Subsequent communication is faster
• Some skeletons may be left unreferenced

53
Home-Based Approaches

• Home location --- always knows current location
  of mobile guy
• Can be used with forwarding pointers
• Or with Mobile IP
• Mobile IP on next slide

54
Home-Based Approaches

• Mobile IP
• Suppose host A is mobile
• Host A has a fixed IP address
• Host A has a home agent
• Home agent of A is at As fixed IP address
• Host A requests temp address at new location
• Care-of address is current location of A
• Home agent knows As care-of address

55
Home-Based Approaches

• Mobile IP

56
Hierarchical Approaches

• Network divided into domains
• Called them layers in DNS
• Top level domain spans network
• Lowest level is leaf domain
• Directory node for each domain

57
Hierarchical Approaches

• Hierarchy of location service domains
• Each domain has associated directory node

58
Hierarchical Approaches

• Let Dir(D) be directory for domain D
• Location record in dir(D) for each entity
  currently in D
• Suppose entity E is in D
• Then chain of pointers to E thru higher level
  directories of D
• E might have more than one address
• Due to replication

59
Hierarchical Approaches

• Entity with two addresses

60
Hierarchical Approaches

• Looking up location of E
• Efficient way to find current location of E

61
Hierarchical Approaches

• To create a replica of E in domain D

• Find first node that knows about E
• Create chain of forwarding pointers to new node

62
Pointer Caches

• Caching good if data seldom changed
• If mobile, addresses change
• But if move is within a domain
• Then pointers at higher nodes does not change
• It might make sense to cache such info
• How to find the right domain?
• Travel regularly between LA and SJ (next slide)
• When to invalidate cache entry?
• Travel to NY or moved there (next next slide)

63
Pointer Caches

• Caching reference to directory node of
  lowest-level domain

64
Pointer Caches

• Cache entry needs to be invalidated because
• Entry returns a nonlocal address
• A local address is available

65
Scalability

• The biggest issue with hierarchical approach is
  scalability
• Root has to know about everybody!
• Storage may be an issue
• Lookup is likely bottleneck
• Possible solutions (read the book)
• Partitioning and/or uniform placement of subnodes

66
Scalability Issues

• Uniform placement of subnodes???

67
Unreferenced Entities

• What if entity is no longer referenced?
• A distributed garbage collection problem
• Recall that for remote objects
• State is remote
• Client-side proxy
• Server-side skeleton
• Assume that an object can be accessed only if a
  remote reference exists
• If no reference exists, then garbage

68
Unreferenced Objects

• Other type of garbage

69
Partial Solutions

• Reference counting
• Keep running count of no. of references
• When count reaches 0, remove object
• Reference listing
• Skeleton maintains explicit list of proxies that
  know about it
• Tracing
• Above methods do not deal with loops, etc.
• Tracing follow all paths from root

70
Reference Counting

• Keep track each time reference is added or
  deleted
• Easy in non-distributed systems
• But unreliable communication causes problems

71
Reference Counting

• If communication is unreliable
• How to maintain accurate reference count?

72
Reference Counting

• Incrementing the counter too late (example of a
  race condition)
• Is this a solution to the problem ???

73
Advanced Reference Counting

• Weighted reference counting
• Object has a fixed total weight
• And variable partial weight
• Only decrement operation allowed
• Weight is split up (partial weights) when new
  references are created
• Delete decrement by partial weight
• Skeletons total weight is decremented

74
Advanced Reference Counting

• Initial assignment of weights
• Weight assignment for a new reference

75
Advanced Reference Counting

• Weight assignment when copying reference

76
Advanced Reference Counting

• Problems?
• Requires reliable communication
• Ditto for reference counting
• Does not deal with loops
• Ditto ditto
• Only a limited number of references
• We can finesse this

77
Advanced Reference Counting

• When partial weight has reached 1
• Use indirection to add more weight

78
Advanced Reference Counting

• Dont like indirection? Fine!
• Generation reference counting (no weights)
• Skeleton maintains array G
• Gi is number of copies at generation i
• When deleting, send msg to skeleton
• Proxys generation no., k, and no. of copies
  made, n
• Skeleton decrements its Gk by 1
• Skeleton increments its Gk1 by n
• When all Gi are 0, the object is deleted

79
Advanced Reference Counting

• Generation reference counting
• Still requires reliable communication
• Can add references w/o contacting skeleton

80
Tracing

• Reference counting does not help with loops and
  such
• One approach is mark and sweep
• Follow all paths from root
• Mark all places reached
• Then sweep through everything and
• remove everything not marked
• This can be done in distributed systems
• But requires stop the world synchronization

81
Tracing

• More practical for dist. systems is
• Tracing in groups
• Group is a collection of processes
• For scalability
• Algorithm
• Mark skeletons
• Propagate marks from skeletons to proxies
• Propagate marks from proxies to skeletons
• Iterate previous 2 steps on larger groups
• Garbage reclamation

82
Tracing in Groups

• Initial marking of skeletons

83
Tracing in Groups

• Final marking

84
Summary

• Naming is a serious issue!
• Types of names
• Address
• Identifier
• Human-friendly
• Naming/naming graph
• Human-friendly is not mobile-friendly

85
Summary

• Mobility
• Broadcasting/multicasting
• Forwarding pointers
• Home location
• Hierarchical search tree
• Unreferenced objects
• Reference counting
• Tracing