Naming

1. Naming Chapter 4

2. Names • A name is a string of bits or characters that is used to refer to an entity • An entity can be practically anything • In a distributed system: • hosts, printers, disks, files, graphical windows • users, mailboxes, newsgroups, Web pages, • messages, network connections and so on

3. Naming • Names: • Play an important role in all computer systems • Used to uniquelyidentify entities • Name resolution allows a process to access the named entity • In a distributed system: • The implementation of a naming system is itself often distributed across multiple machines • How this distribution is done plays a key role in the efficiency and scalability of the naming system

4. Desired Properties of Names • 􀂄 Addresses are not good candidates fornaming entities. − Change with system reorganization − Can have multiple addresses • 􀂄 Names should be stable. • 􀂄 Names should be location independent. • 􀂄 Names should be platform independent. • 􀂄 Names should be easily resolvable.

5. Name Spaces (1) • A leaf node represents a named entity • A directory node has a number of outgoing edges, each labeled with a name and stores a directory table in which an outgoing edge is represented • A node can be represented by differentpathnames(absolute / relative) • /home/steen/keys as well as /keys hard linksto node n5

6. Linking and Mounting (1) • Strongly related to name resolution is the use of aliases • An alias is another name for the same entity • /keys is a symbolic link to node n6. Instead of storing the address or state of that entity, n5 stores an absolute path name

7. Linking and Mounting (2) • Consider a collection of name spaces distributed across different machines • Each name space is implemented by a different server, each possibly running on separate machines • If we want to mount a foreign name space NS2 into a name space NS1, it may be necessary to communicate over a network • To mount a foreign name space in a distributed system requires at least the following information • The name of an access protocol • The name of the server • The name of the mounting point in the foreign name space

8. Linking and Mounting (3) /remote/vu/mbox mount point mounting point • nfs access protocol :// name space delimiter • flits.cs.vu.nl name of the server home/steen mounting point

9. Linking and Mounting (4) • Organization of the DEC Global Name Service (GNS)Add a new root node and make the existing root nodes its children

10. Linking and Mounting (5) • A problem with GNS is that existing names need to be changed • The absolute path name/home/steen in NS1 has now changed into a reletive path name that is to be resolved starting in node n0and corresponds to the absolute path name /vu/home/steen • To solve these problems, names in GNS (implicitly) include a node identifier from where resolution should normally start • /home/steen/keys n0:/home/steen/keys • This expansion is hidden from users and different name spaces have different node identifiers • If thousands of name spaces are merged, this approach will eventually lead to performance problems

11. Implementation of a Name Space • A name space forms the heart of a naming service • Naming service allows users and processes to add, remove, and look up names • Naming service is implemented by name servers • In local area, only a single name server is sufficient • In large-scale distributed systems with many (billions) entities, possibly spread across a large geographical area, it is necessary to distribute the implementation of a name space over multiple name servers

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

13. 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

14. Implementation of Name Resolution (1) • The principle of iterative name resolution for • ftp://ftp.cs.vu.nl/pub/globe/index.txt

15. Implementation of Name Resolution (2) • The principle of recursive name resolutionfor • ftp://ftp.cs.vu.nl/pub/globe/index.txt

16. Implementation of Name Resolution (3) • Recursive name resolution of <nl, vu, cs, ftp> • Name servers cache intermediate results for subsequent lookups

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

18. Locating Mobile Entities • The naming services discussed so far, are primarily used for naming entities that have a fix location • Traditional naming systems are not well suited for supporting mobile entities • Consider updating the address of ftp.cs.iku.edu.tr, because the ftp server is to be moved to a different machine, as long as the server is moved to a machine within the cs.iku.edu.tr domain, the update can be done efficiently • If ftp.cs.iku.edu.tr were to move a machine named ftp.cs.vu.nl, which lies in a completely different domain, changing all links to it become invalid • Solution is to record the address (or name) of the new machine in the DNS database for cs.iku.edu.tr

19. Naming versus Locating Entities • Direct, single level mapping between names and addresses. • T-level mapping using identities.

20. Simple Solutions for Locating Entities • Forwarding Pointers:Each time an entity moves, it • leaves behind a pointer telling where it has gone to • Broadcasting:Simply broadcast the ID, requesting the entity to return its current address • Drawbacks: • Can never scale beyond local-area networks • Requires all processes to listen to incoming location requests

21. Forwarding Pointers (1) The principle of forwarding pointers using(proxy, skeleton)pairs Drawbacks: • 1) a chain can become so long • 2) vulnerability to broken links • 3) intermediate locations have to maintain their part of the chain

22. Forwarding Pointers (2) • Redirecting a forwarding pointer, by storing a shortcut in a proxy

23. Home-Based Approaches (1) • Let a homekeep track of where the entity is: • An entity’s home addressis registered at a naming service • The home registers the foreign addressof the entity • Clients always contact the home first, then continues with the foreign location

24. Home-Based Approaches (2) • Problems with home-based approaches: • Increase a communication latency • The home address has to be supportedas long as theentity lives • The home address is fixed, which means an unnecessary burden when the entity permanently moves to another location • Poor geographical scalability (the entity may be next to the client) Question: How can we solve the permanent moveproblem?

25. Hierarchical Approaches (1) corresponds to a local area network • Hierarchical organization of a location service into domains • Each having an associated directory node that keeps track of the entities in that domain

26. Hierarchical Approaches (2) • An example of storing information of a replicated entity having two addresses in different leaf domains

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

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

29. Pointer Caches (1) • Consider a mobile entity Emoves regularly within a domain D • It is effective to cache a reference to the directory node D

30. Pointer Caches (2) Question:When to invalidate a cache entry? • A cache entryneeds to be invalidated because it returns a nonlocal address, while such an address is available

31. Scalability Issues (1) • The root node is required to store a location record for each entity and to process requests for each entity • Suppose the size of each location record is 1 KB, required storage capacity for a billion entities is 1 terabyte • The real problem is the root may be required to handle so many lookup and update requests that it will become bottleneck • The solution is to partition the root node and other high-level directory nodes into subnodes • Suppose partition root node into 100 subnodes, the question is where to physically place each subnode in the network

32. Scalability Issues (2) • The scalability issues related to uniformly placing subnodes of a partitioned root node across the network covered by a location service

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

34. Simple Reference Counting (1) • Each time a reference to an object is created, a reference counter for that object is incremented • When a reference is removed, the reference counter is decremented • The problem of maintaining a proper reference count in the presence of unreliable communication

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

36. Tracing in Groups (1) • Processes in a large distributed system are organized into groups • Garbage-collection takes place within groups through a combination of mark-and-sweepand reference counting • Initial marking; only skeletons are soft marked

37. Tracing in Groups (2) • Intraprocess (local) propagation of marks from skeletons to proxies

38. Tracing in Groups (3) • Interprocess propagation of marks from proxies to skeletons