1. Naming Chapter 4

2. Table of Contents Concepts Locate mobile entities Garbage collection

3. 4.1 Naming Entities What’s the most important requirement for a name? Convenient and Unique

4. Can you image the longest English name in the world? Take a breath Mr. Adolph Blaine Charles David Earl Frederick Gerald Hubert Irvin John Kenneth Lloyd Martin Nero Oliver Paul Quincy Randolph Sherman Thomas Uncas Victor William Xerxes Yancy Wolfeschlegelsteinhausenbergerdorffwelchevoralternwarengewissensch aftschaferswessenschafewarenwohlgepflegeundsorgfaltigkeitbeschutze nvonangreifeudurchihrraubgierigfeindewelchevoralternzwolftausendjah resvorandieerscheinenerscheinenvanderersteerdemenschderraumschiffg ebrauchlichtalsseinursprungvonkraftgestartseinlangefahrthinzwischenst ernaitigraumaufdersuchenachdiesternwelchegehabtbewohnbarplaneten kreisedrehensichundwohinderneurassevonverstandigmenschlichkeitkon ntefortpflanzenundsicherfeuenanlebenslanglichfreudeundruhemitnichei nfurchtvorangreifenvonandererintelligentgeschopfsvonhinzwischentern art Zeus igraum Senior

5. He was born in Munich in 1904 and lived in Philadelphia for most of his life. Apparently he shortened his name to Wolfeschlegelsteinhausenbergerdorff, and subsequently went by Hubert Blaine Wolfe, but the "Senior" indicates that he passed some form of his name to his son. The full version of the name of 590 letters appeared in the 12th edition of The Guinness Book of Records. He now lives in Philadelphia, Pennsylvania, U.S.A., and has shortened his surname to Mr. Wolfe + 585, Senior.

6. (2003-03-04) 姓名最长的是藏族代表 藏族代表姓名 13 字长，姓王代表 230 人居首。 这次到北京的人大代表中，姓名最长的是藏族代表嘉 木样．洛桑久美．图丹却吉尼玛，共有 13 个字。最特 别的姓名有战永胜、种明辉、锁飞、揭国雄、娘毛先 等。资格最老的代表是申纪兰，这是她第十次当选全 国人大代表，亦是唯一一个从第一届担任到第十届的 人大代表。此外，人数最多的姓是王，共 230 人，紧随 其后的是姓李的 226 人，而姓种、锁、漆、揭、娘、焉 和初等罕见姓氏的代表，则各只有一位。 >>> 2003 年两会专题

7. 4.1 Naming Entities Definition –A name in a distributed system is a string of bits or characters that is used to refer to an entity. –An access point is yet special kind of entity to be used to access some entity, i.e. phone #. – The name of an access point is called an address.

8. 4.1 Naming Entities Identifier: uniquely identify an entity. –An identifier refers to at most one entity –Each entity is referred to by at most one identifier –An identifier always refers to the same entity (i.e., it is never reused) phone #, passport #

9. 4.1 Naming Entities Addresses and identifiers are normally represented in machine- readable form, bit strings. A human-friendly name is generally represented as a character sting. www.njust.edu.cn

10. 4.1 Naming Entities Name spaces –Labeled (acyclic) directed graph Leaf node: 0 outgoing edges Directory node: n outgoing edges –Root node –Path name Form: N: Absolute path name Relative path name

11. Name Spaces (1) A general naming graph with a single root node.

12. Name Spaces (2) The general organization of the UNIX file system implementation on a logical disk of contiguous disk blocks.

13. 4.1 Naming Entities Name resolution –The process of looking up a name. N: –Closure Mechanism Knowing how and where to start name resolution. –4340880245810362 –/home/yangzhao/movie –$HOME

14. 4.1 Naming Entities Name resolution –Linking An alias is another name for the same entity, for example, an environment variable. Alias implementation –Hard links: multiple absolute paths names to the same node –Symbolic link: storing an absolute path name in the leaf node Why aliasing?

15. Linking and Mounting (1) The concept of a symbolic link explained in a naming graph.

16. 4.1 Naming Entities Name resolution –Mounting Let a directory node store the identifier of a directory node from a different name space, which we refer to as a foreign name space. Mount point vs. Mounting point Mounting implementation –The name of an access protocol –The name of the server –The name of the mounting point in the foreign name space

17. Linking and Mounting (2) Mounting remote name spaces through a specific process protocol.

18. 4.1 Naming Entities Name resolution –Mounting Example –nfs://flits.cs.vu.nl/home/steen cd /remote ls -l Transparent

19. 4.1 Naming Entities Name resolution –Global Name Service (GNS) Add a new root node and to make the existing root nodes its children. /home/steen/keys => n0:/home/steen/keys

20. Linking and Mounting (3) Organization of the DEC Global Name Service

21. 4.1 Naming Entities Name Space Layer –Global layer close to root node, rarely updated –Administrational layer organizations, groups of entities –Managerial layer nodes for hosts user-defined directories and files A zone is a part of the name space that is implemented by a separate name server.

22. Name Space Distribution (1) An example partitioning of the DNS name space, including Internet-accessible files, into three layers.

23. 4.1 Naming Entities Availability Performance Client-side Caching Replication

24. 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. ItemGlobalAdministrationalManagerial Geographical scale of networkWorldwideOrganizationDepartment Total number of nodesFewManyVast numbers Responsiveness to lookupsSecondsMillisecondsImmediate Update propagationLazyImmediate Number of replicasManyNone or fewNone Is client-side caching applied?Yes Sometimes

25. 4.1 Naming Entities Implementation of Name resolution –Local name resolver Ensuring that the name resolution process is carried out –Iterative name resolution –Recursive name resolution root: Root server is assumed to be known.

26. Implementation of Name Resolution (1) The principle of iterative name resolution.

27. Implementation of Name Resolution (2) The principle of recursive name resolution.

28. Implementation of Name Resolution (3) Recursive name resolution of. Name servers cache intermediate results for subsequent lookups. Server for node Should resolve Looks up Passes to child Receives and caches Returns to requester cs # -- # vu # # # # ni # # # # # # root # # # # # # # #

29. 4.1 Naming Entities Comments on the recursive name resolution -: puts a higher performance demand on each name server +: caching results is more effective +: communication costs may be reduced

30. Implementation of Name Resolution (4) The comparison between recursive and iterative name resolution with respect to communication costs.

31. The DNS Name Space The most important types of resource records forming the contents of nodes in the DNS name space. Type of record Associated entity Description SOAZoneHolds information on the represented zone AHostContains an IP address of the host this node represents MXDomainRefers to a mail server to handle mail addressed to this node SRVDomainRefers to a server handling a specific service NSZoneRefers to a name server that implements the represented zone CNAMENodeSymbolic link with the primary name of the represented node PTRHostContains the canonical name of a host HINFOHostHolds information on the host this node represents TXTAny kindContains any entity-specific information considered useful

32. DNS Implementation (1) An excerpt from the DNS database for the zone cs.vu.nl.

33. DNS Implementation (2) Part of the description for the vu.nl domain which contains the cs.vu.nl domain. NameRecord typeRecord value cs.vu.nlNISsolo.cs.vu.nl A130.37.21.1

34. The X.500 Name Space (1) A simple example of a X.500 directory entry using X.500 naming conventions. AttributeAbbr.Value CountryCNL LocalityLAmsterdam OrganizationLVrije Universiteit OrganizationalUnitOUMath. & Comp. Sc. CommonNameCNMain server Mail_Servers--130.37.24.6, 192.31.231,192.31.231.66 FTP_Server--130.37.21.11 WWW_Server--130.37.21.11

35. The X.500 Name Space (2) Part of the directory information tree.

36. The X.500 Name Space (3) Two directory entries having Host_Name as RDN. AttributeValueAttributeValue CountryNLCountryNL LocalityAmsterdamLocalityAmsterdam OrganizationVrije UniversiteitOrganizationVrije Universiteit OrganizationalUnitMath. & Comp. Sc.OrganizationalUnit Math. & Comp. Sc. CommonNameMain serverCommonNameMain server Host_NamestarHost_Namezephyr Host_Address192.31.231.42Host_Address192.31.231.66

37. 4.2 Locating Mobile Entities Names –Human-friendly names –Addresses –Identifiers Traditional naming systems –Human-friendly names maps to addresses –Both names and addresses can change

38. Naming versus Locating Entities a)Direct, single level mapping between names and addresses. b)Two-level mapping using identities.

39. 4.2 Locating Mobile Entities Locating an entity –Broadcasting A message with an entity ID is broadcast Each machine checks whether it has the entity One replies –Multicasting A group of hosts receives the request +: locate the nearest replica

40. 4.2 Locating Mobile Entities Locating an entity –Forwarding Pointers An entity moves from A to B A reference to B is left at A Locating an entity is followed by the chain of forwarding pointers. +: simple -: a chain can be very long => inefficient (space, time) -: a chain is easy to be broken

41. Forwarding Pointers (1) The principle of forwarding pointers using (proxy, skeleton) pairs.

42. Forwarding Pointers (2) Redirecting a forwarding pointer, by storing a shortcut in a proxy. Sending the response directly to the initiating proxy or along the reverse path of forwarding pointers

43. If a process in a chain of (proxy, skeleton) pairs crashes: A object’s home location always keep a reference to its current location

44. 4.2 Locating Mobile Entities Locating an entity –Home-based Approaches Home location –keeps track of the current location of an entity –is often chosen the place where an entity was created normally +: improve the previous two approaches: scalability and performance problems -: always contact the home location first -: fixed home location

45. Home-Based Approaches The principle of Mobile IP.

46. 4.2 Locating Mobile Entities Locating an entity –Hierarchical Approaches Multiple-tiered home-based approach A network is divided into a collection of domains Leaf domain is the lowest-level domain dir(D): entities in the domain D root node: knows about all entities

47. Hierarchical Approaches (1) Hierarchical organization of a location service into domains, each having an associated directory node.

48. 4.2 Locating Mobile Entities –Location record A location record for entity E in the directory node N for a leaf domain D contains the entity’s current address in that domain The directory node N’ for the next higher-level domain D’ that contains D will have a location record for E containing only a pointer to N. Likewise, the parent node of N’ will store a location record for E containing only a pointer to N’.

49. Hierarchical Approaches (2) An example of storing information of an entity having two addresses in different leaf domains.

50. 4.2 Locating Mobile Entities –Lookup operation A client wishing to locate an entity E, issues a lookup request to the directory node of the leaf domain D in which the client resides. If the directory node does not store a location record for E, then E is not located in D currently. Go for D’s parent (next level higher), and so on. Once the request reaches a node M that stores a location recode for E, then E is in dom(M).

51. Hierarchical Approaches (3) Looking up a location in a hierarchically organized location service.

52. 4.2 Locating Mobile Entities –Locality The entity is searched in a gradually increasing ring centered around the requesting client. The search area is expanded each time the lookup request is forwarded to a next higher- level directory node The worst case is that the request reaches the root node.

53. Hierarchical Approaches (4) a)An insert request is forwarded to the first node that knows about entity E. b)A chain of forwarding pointers to the leaf node is created.

54. 4.2 Locating Mobile Entities –Pointer Caches Caching is effective only if the cached data rarely change If a mobile entity E always moves within a domain D, then the path of pointers for entity E from the root node to dir(D) does not have to change. A reference to dir(D) can, in principle, be cached at every node along the path from the leaf node where the lookup was initiated.

55. Pointer Caches (1) Caching a reference to a directory node of the lowest-level domain in which an entity will reside most of the time.

56. 4.2 Locating Mobile Entities –Pointer Caches dir(D) store a pointer to –Originally: the subdomain where E currently resides –Possible Improvement: the actual address of E directly Open questions –How to find the best directory node to store the current address of mobile entity? »Least upper bound –When to invalidate a cache entry?

57. Pointer Caches (2) A cache entry that needs to be invalidated because it returns a nonlocal address, while such an address is available.

58. 4.2 Locating Mobile Entities –Scalability Issues The root may be required to handle so many lookup and update requests => bottleneck Solution: partition the root node and other high-level directory nodes into subnodes. Each subnode is responsible for handling the requests related to a specific subset of all the entities that are to be supported by the location service. Deciding which subnodes should handle which entities in very large-scale location services is still an open question.

59. Scalability Issues The scalability issues related to uniformly placing subnodes of a partitioned root node across the network covered by a location service.

60. 4.3 Removing Unreferenced Entities General concept about objects –If an object is referenced by some pointers, it can be accessed and used. –If an object can no longer be accessed, it should be removed. Explicitly or Implicitly ? Language-dependent

61. 4.3 Removing Unreferenced Entities It’s always very hard to make sure whether or not an entity is referred by someone, especially in DS. Distributed garbage collectors Assumption: –An object can be accessed only if there is a remote reference to it –An object for which no remote reference exists should be removed.

62. 4.3 Removing Unreferenced Entities Is this true? Having a remote reference to an object means that the object will ever be accessed or the object is not a garbage?

63. The Problem of Unreferenced Objects An example of a graph representing objects containing references to each other.

64. 4.3 Removing Unreferenced Entities DGC (Distributed garbage collection) –Requires network communication –Efficiency and scalability –Possible failures in communication, machines or processes –Several solutions Reference Counting Reference Listing Tracing-based

65. Reference Counting Simple Reference Counting –Steps: Each object stores its own reference counter in its associated skeleton When a process P creates a reference to a remote object O, it first installs a proxy then requires the counter in O to be increased by one. When a remote reference is to be removed, the counter is decreased by one. –Two problems

66. Reference Counting (1) The problem of maintaining a proper reference count in the presence of unreliable communication.

67. Reference Counting (2) a)Copying a reference to another process and incrementing the counter too late b)A solution.

68. Reference Counting Advanced Reference Counting –Weighted reference counting Each object has a fixed total weight When the object is created, the total weight is stored in its associated skeleton, along with a partial weight, which is initialized to the total weight. When a new remote reference (p,s) is created, half of the partial weight stored in the object’s skeleton is assigned to the new proxy p.

69. Reference Counting Advanced Reference Counting –Weighted reference counting When a reference is removed, the total weight of the object is subtracted the partial weight of the removed reference.

70. Advanced Referencing Counting (1) a)The initial assignment of weights in weighted reference counting b)Weight assignment when creating a new reference.

71. Advanced Referencing Counting (2) c)Weight assignment when copying a reference.

72. Reference Counting Advanced Reference Counting –Weighted reference counting Problem? Only a limited number of references can be created.

73. Advanced Referencing Counting (3) Creating an indirection when the partial weight of a reference has reached 1.

74. Reference Counting Advanced Reference Counting –Weighted reference counting New problem ? –Forwarding pointer: long chains degrade performance and is easy to be broken. New solution: generation reference counting –G[i] in skeleton: denotes the number of outstanding copies for generation I; –If a proxy p is removed, it sends (k,n) to the skeleton: »G[k] = G[k] – 1; G[k+1] =G[k+1]+n

75. Advanced Referencing Counting (4) Creating and copying a remote reference in generation reference counting.

76. Reference Listing Description Instead of counting references, a skeleton maintains an explicit reference list of all proxies that point to it. More information, better service Adding or removing proxies are idempotent operations (operations that can be repeated without affecting the end result) Keep sending a message to add its proxy, stops as soon as delivery has been acknowledged. The skeleton knows which proxies are up, which are down.

77. Identifying Unreachable Entities Tracing-based GC –Mark-and-sweep Mark phase: entities are traced by following chains of references originating from entities in the root set. (3-color algorithm) Sweep phase: remove the entities that have not been marked. Main drawback: “stop-the-world” synchronization is often not acceptable for DGC Possible improvement: incremental GC, but …

78. Identifying Unreachable Entities Tracing-based GC –Tracing in Groups (scalability) GC takes place within groups through a combination of mark-and-sweep and reference counting A group is simply a collection of processes. Basic idea: –Collect all garbage within a group –Consider a larger group that encompasses a number of subgroups which have just been cleaned up.

79. Identifying Unreachable Entities Algorithm of collecting garbage within a group –Initial marking, in which only skeletons are marked. –Intraprocess propagation of marks from skeletons to proxies –Interprocess propagation of marks from proxies to skeletons –Stabilization by repetition of the previous two steps. –Garbage reclamation A skeleton can be marked either soft or hard A proxy can be marked none, soft, or hard

80. Identifying Unreachable Entities A skeleton is hard: it is either reachable from a proxy in a process outside the group, or reachable from a root object inside of the group A skeleton is soft: it is reachable only from proxies inside the group. A soft skeleton can be changed into hard, but not the other way around.

81. Identifying Unreachable Entities A proxy is hard: it is reachable from an object in the root set. A proxy is soft: it is reachable from a skeleton that has been marked soft as well. A soft proxy cannot be changed into hard. A proxy is none: it is not reachable. A none proxy can be changed into soft or hard.

82. Identifying Unreachable Entities Marking algorithm –A skeleton is marked either soft or hard, depending on whether it can be reached from a proxy outside the group. –Each process run its own local garbage collector requiring to propagate marks from skeletons to proxies within the process it is running. –Marks are propagated between different processes. Soft marks do not have to be propagated since the first step already did this.

83. Tracing in Groups (1) Initial marking of skeletons.

84. Tracing in Groups (2) After local propagation in each process.

85. Tracing in Groups (3) Final marking.