1 Naming Names are used to uniquely identify resources/services. Name resolution: process to determine the actual entity that a name refers to. In distributed settings, the naming system is often provided by a number of sites.

2 Names and Addresses Name is a string of bytes used to refer to an entity. Examples: –Processes, mailboxes, printers, disk, files, web-pages, messages, NICs etc. Access Point = Address of the entity to be addressed. Nice attribute: name should be independent of the address (location independent). Addresses: 32/64 bit-string (48bits for Ethernet addresses vs. User-friendly-names (in Unix each file can have upto 255 bytes name).

3 Name Spaces Names are organized in name spaces (that get to be represented as labeled/directed graphs). Leaves (basic element). Directory Nodes work with the help of directory tables. Paths –roots –Relative paths –Absolute path names Global vs. local names. –Local name is interpreted within context.

4 Name Spaces A general naming graph with a single root node. For n5 there are two ways to get “reached” Is it possible to have more than one roots?

5 Another Example of Name Spaces The general organization of the UNIX file system implementation on a logical disk of contiguous disk blocks. Boot block, Super-block, I-nodes & blocks The implementation of the FS and the Logical naming are different How is name resolution is done here??

6 Linking in a Name Space The concept of a symbolic link explained in a naming graph. Difference between symbolic/hard links?

7 Mounting Mounting remote name spaces through a specific process protocol. If two name spaces exist NS1, NS2 – to mount a foreign entity in a DS –Name the access protocol –Name the server –Name the mounting point

8 DEC’s Global Name Service Idea: add a new root and make all existing roots children Problems? –/home/steen/mbox should be n0:/home/steen/mbox (names need to change!) –If thousands of nodes are connected this approach has also performance problems

9 Organizing Name Spaces for DSs To effectively implement a Large-Scale naming System the name space has to be partitioned into a number of layers: –Global Leyer (high level nodes) –Administrative Leyer (manages names within a single organization) –Managerial Leyer (name spaces that may often change) –DNS – Domain Name Service is such an example.

10 DNS An example partitioning of the DNS name space, including Internet-accessible files, into three layers.

11 Performance of DNS Zones: non-overlapping sections of the name space Zones are implemented by different name servers. Due to few changes in the upper levels of the hierarchy, the entries for names in these domains remain unchanged for a long time –Clients can use their own local caches to store resolutions of addresses (for some time). –In the first lookup you got to pay all the penalties. –Second time around, penalties go away (if you try to access/make name resolution of the same entity). Name servers can be replicated (for availability).

12 Name Space Distribution 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 Delays for name servers within admin/managerial levels should “reflect” changes within a few millisecs if they are to be effective.

13 Implementation of Name Resolution The principle of iterative name resolution. Name Resolver: package that undertakes the execution of the name resolution in a zone. Fetch file ftp:/pub/globe/index.txt at cs.vu.nl Absolute name is

14 Recursive Implementation of Name Resolution The principle of recursive name resolution. Minus: puts more (excessive?) load on the name servers Pluses: –caching results are more effective –Communication costs may be reduced.

15 Overview of Name Resolution in Recursive NR. 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 # # # # # # # #

16 Comparison of Iterative/Recursive Resolution The comparison between recursive and iterative name resolution with respect to communication costs. In iterative name resolution, caching is restricted to clients only. If two clients (from the same zone) ask for the resolution of the same entity, the same job has to get done twice. Compromise: a local name server used by all users/clients is in place (caching results of name resolution)

17 The DNS Name Space DNS is used to find hosts, mail-servers, web-servers, ftp-servers etc. DNS is organized in a hierarchical tree A path consist of labels (each label being upto 63 characters) Paths are upto 255 characters long A subtree is called domain (and has a domain name) The content of a node is formed by a collection of resource records

18 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

19 DNS Implementation An excerpt from the DNS database for the zone cs.vu.nl.

20 DNS Implementation Part of the description for the vu.nl domain which contains the cs.vu.nl domain. NameRecord typeRecord value cs.vu.nlNSsolo.cs.vu.nl A

21 The X.500 Name Space 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 , , FTP_Server WWW_Server Directory Service Look-up an entity based on a description of properties (than name) Similar to Yellow-Page look up. X.500 consists of a number of records

22 X.500 Part of the directory information tree. The collection of all entries makes up the Directory Information Base (DIB) Each record is uniquely naked and can be looked up. Each record is called RDN (Relative Distinguished Name). Calling read(/C=NL/O=Vrije Universiteit/OU=Math & Comp. Sc./CN=Main server) will return the entry of the previous slide).

23 X.500 Two directory entries having Host_Name as RDN. AttributeValueAttributeValue CountryNLCountryNL LocalityAmsterdamLocalityAmsterdam OrganizationVrije UniversiteitOrganizationVrije Universiteit OrganizationalUnitMath. & Comp. Sc.OrganizationalUnitMath. & Comp. Sc. CommonNameMain serverCommonNameMain server Host_NamestarHost_Namezephyr Host_Address Host_Address Calling list(/C=NL/O=Vrije Universiteit/OU=Math & Comp. Sc./CN=Main server) will produce…

24 X.500 Implementation DIT is “partitioned” across several servers (termed Directory Service Agents [DSA]- similar to zones in DNS) Clients are represented by Directory User Agents (DUA) What is different between X.500-DNS? –Provides facilities for querying a DIB – answer = search(“&(C=NL)(O=Vrije Universiteit)(OU=*)(CN=Main Server)) –Find all the “main servers” –An operation may be “expensive” – the above will have to search all entries for all departments and combine the results.. LDAP (Lightweight Directory Access Protocol) is used to accommodate X.500 directory services in the Internet.

25 Locating Mobile Entities Problem Statement: what happens and how names are resolved when entities are mobile? –Example: move ftp.di.uoa.gr to ftp.cs.ucr.eduftp.di.uoa.grftp.cs.ucr.edu –How is the change addressed? Record the new address in the DNS database of di.uoa.gr Record the the name (instead of the address) – symbolic link. –For highly mobile entities both solutions are problematic (especially if there are multiple phases in the name resolution/address determination).

26 Naming versus Locating Entities Another idea is to separate naming from locating by introducing identifiers. An identifier does not have a human-friendly representation (optimized for machine processing only). Each time an entity changes location, the mapping needs to change! This happens in (a) below where there is a single level mapping between names and addresses.

27 Simple Solution: Forwarding Pointers The principle of forwarding pointers using (proxy, skeleton) pairs. Principle: when an entity moves from A to B, it leaves behind A reference to its new location at B. If entity is a distributed Object that moves from one location (with Process P3) to another (with process P4) When an object moves leaves behind a proxy..

28 Forwarding Pointers Redirecting a forwarding pointer, by storing a shortcut in a proxy. When no skeleton references a proxy, the skeleton can be removed. Instead of dealing with proxies, a chain (proxy, skeleton) can be short cut. The current location is piggybacked with the response of the distributed object.

29 The Home-based Approach Forwarding does not work in large scale systems. Home-based approaches are doing a bit better –Home location(keeps track of the current location of an entity) –Home agent (manages the entities within a location). –Home location often the place where the object is created. A home-agent receives a packet for a mobile host Looks-up the host’s current location If it is currently in the local network, the packet is forwarded Otherwise, it is sent to the host’s new address (care of) At the same time the sender, is alerted about the new location. This new location can be used now as the address of the entity.

30 Home-Based Approach The principle of Mobile IP [Perkins 97]

31 Alternatives: The Hierarchical Approach Hierarchical organization of a location service into domains, each having an associated directory node. Leaf-domains correspond to LANs Each domain D has an associated directory dir(D) that keeps track of the entities in the domain.

32 The Hierarchical Approaches An example of storing information of an entity E having two addresses in different leaf domains. M is the parent (common ancestor) for both copies of E in domains D1 and D2.

33 Look-up in the Hierarchical Approach Looking up a location in a hierarchically organized location service. Progressively move up until a entry about E is found. –Then move downward onto the object

34 Insertion of Location Identifiers in the Hierarchical Approach 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.

35 Pointer Caches Caching a reference to a directory node of the lowest-level domain in which an entity will reside most of the time. If a user moves within domain D then cached pointers have to point to D-dir (if the look-up operations in the multiple levels are to be useful).

36 Problems with Pointer Caches A cache entry that needs to be invalidated because it returns a nonlocal address, while such an address is available. Let’s assume that a new address is available locally..

37 Scalability Issues The scalability issues related to uniformly placing subnodes of a partitioned root node across the network covered by a location service. Solution: take the birthplace of E into account (while distributing subnodes of address identifiers). Problem: root has to store large amount of information Solution: divide and conquer (do it uniformly?)

38 The Problem of Unreferenced Objects An example of a graph representing objects containing references to each other. Problem Statement: Garbage Collection in the Network

39 Solution of Reference Counting The problem of maintaining a proper reference count in the presence of unreliable communication. The same can happen when a process ceases to reference an object. An object’s skeleton stores its own reference count When the counter is zero the object can be removed.

40 Copying a Reference using Counting Copying a reference to another process and incrementing the counter too late A solution: A process has to get an ACK from the object The object cannot be removed if an ACK is out (P2 was “seen” by O). In a large-scale system the “three” messages will create problems..

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

42 Advanced Referencing Counting c)Weight assignment when copying a reference. Main Problem: only a limited number of references can be created…

43 Advanced Referencing Counting Creating an indirection when the partial weight of a reference has reached 1.

44 Advanced Referencing Counting Creating and copying a remote reference in generation reference counting.

45 Tracing in Groups Initial marking of skeletons.

46 Tracing in Groups After local propagation in each process.

47 Tracing in Groups Final marking.