Naming. Name Service. Why Name Services? Mappings. and enhanced concepts

Transcription

1 Name Service Naming and enhanced concepts Processes and Threads: execution of applications or services Communication: information exchange and coordination of processes But: how can client processes or human users find the right server processes for communication? Name Service, Naming (e.g. DNS, GNS) Central concept in distributed systems Mapping of logical names to the address of resources (objects, files, services, hosts,...) Directory Service / Discovery Service (e.g. X.500 / Jini Discovery Service) Mapping of service attributes to resource addresses ('yellow page') The client don't need to know the resource name, only a description of its characteristics Why Name Services? Resources are accessed using identifiers or references ¾ An identifier can be stored in variables and retrieved from tables quickly ¾ Identifier includes or can be transformed to an address for an object E.g. NFS file handle, CORBA remote object reference ¾ A name is human-readable value (usually a string) that can be resolved to an identifier or address Internet domain name, file pathname, process number E.g./etc/passwd, For many purposes, names are preferable to identifiers ¾ because the binding of the named resource to a physical location can be changed ¾ because they are more meaningful to users Resource names are resolved by name services ¾ to give identifiers and other useful attributes Mappings Internet DNS (Domain Name Service) Mapping of domain names to host attributes: IP address, Type of entry (host, name server, ,...), Period of validity,... Directory service X.500 Mapping of person names to the person's attributes: address, Phone number,... Middleware platform CORBA Mapping of an object name onto an object reference The given address possibly is one more logical name which has to be mapped onto a resource address, e.g. in case of an IP address

2 Name Resolution: URLs URL ARP lookup DNS lookup Resource ID (IP number, port number, pathname) content/teaching/lectures/sub/vsss02/ Organisation of Naming Information In large systems like the Internet: Large number of entities to be named Distribution of naming information to several hosts Structuring of naming data ¾ Management by local organisations ¾ Better performance by holding less data ¾ Hierarchical structure allows sub-names without name clashes (Ethernet) Network address 2:60:8c:2:b0:5a Socket file Web server Name Spaces Represented by a labelled, directed graph Leaf nodes represent a named entity (contains e.g. address) Directory node has several outgoing, labelled edges Root node mostly is the unique start node of the graph Name Spaces Linking and Mounting (1) Naming of entities by path names to leaf nodes Separation of edge labels by special characters like '/' or '.' Similar concept like in many file systems Distinction between absolute and relative path names Very often, the graph is organised as a tree D Name resolution: looking up information stored in the node identified by a path name Often required: aliases Another name for the same entity Usage of symbolic links: no address is stored in the leaf node, but another path name Merge name spaces: mounting

3 Linking and Mounting (2) Linking and Mounting (3) Directory for mount points required information: name of access protocol name of server name of mounting point mount point mounting point Mounting by setting an alias into a different name space: Network File System (NFS) Alternative approach for merging name spaces: Global Name Service (GNS) Add a new root node and add existing root nodes as children Problem: new root node has to maintain a mapping for old root nodes Name Space Distribution (1) Name Space Distribution (2) ¾ The name space is the core of a naming service ¾ Operations for adding, removing and looking up names ¾ Implemented by name servers Item Geographical scale of network Global Worldwide Administrational Organization Managerial Department Structuring of naming information Total number of nodes Responsiveness to lookups Few Seconds Many Milliseconds Vast numbers Immediate root node and its children: stable nodes Update propagation Lazy Immediate Immediate Nodes that are managed within a single organisation: administrative units Number of replicas Is client-side caching applied? Many Yes None or few Yes None Sometimes Host in local networks, shared files, userdefined directories,...: typically frequently changing nodes A comparison between name servers for implementing nodes from a large-scale name space partitioned into a global layer, an administrational layer, and a managerial layer.

4 Implementation of Name Resolution (1) Iterative name resolution A client s name resolver contacts a name server. This name server passes back a reference to the next responsible name server. The resolver contacts this server,... Implementation of Name Resolution (2) Recursive name resolution A client s name resolver only contacts the next name server. Finding the responsible name server and thus the address now is made by the involved name servers. request address Implementation of Name Resolution (3) Implementation of Name Resolution (4) Server for node Should resolve Looks up Passes to child Receives and caches Returns to requester cs <ftp> #<ftp> #<ftp> vu <cs,ftp> #<cs> <ftp> #<ftp> #<cs> #<cs, ftp> ni <vu,cs,ftp> #<vu> <cs,ftp> #<cs> #<cs,ftp> #<vu> #<vu,cs> #<vu,cs,ftp> root <ni,vu,cs,ftp> #<nl> <vu,cs,ftp> #<vu> #<vu,cs> #<vu,cs,ftp> #<nl> #<nl,vu> #<nl,vu,cs> #<nl,vu,cs,ftp> Recursive name resolution of <nl, vu, cs, ftp>. Name servers cache intermediate results for subsequent lookups (performance improvement). Recursive resolution often helps to decrease communication costs

5 DNS Name Service for the Internet A distributed naming database Name structure reflects administrative structure of the Internet Rapidly resolves domain names to IP addresses ¾ exploits caching heavily ¾ typical query time ~100 milliseconds Scales to millions of computers ¾ partitioned database ¾ caching Resilient to failure of a server ¾ replication Basic DNS algorithm for name resolution (domain name o IP number) Look for the name in the local cache Try a superior DNS server, which responds with: another recommended DNS server the IP address (which may not be entirely up to date) DNS Name Space com edu gov mil cs Oxford Generic The domain Name is given by the sequence of labels, beginning with the root of the target domain, ending with the root of the whole tree. The labels are separated by. winnie com hp corp se de rwth-aachen informatik Countries winnie.corp.hp.com (would be: winnie.corp.hp.com.) Domains and Zones DNS Functions com org Main function is to resolve domain names for computers, i.e. to get their IP addresses ¾ caches the results of previous searches until they pass their 'time to live' edu edu Zone Other functions: berkeley nwu purdue ¾ get mail host for a domain ¾ reverse resolution - get domain name from IP address ¾ Host information - type of hardware and OS ¾ Well-known services - a list of well-known services offered by a host ¾ Other attributes can be included (optional) berkeley.edu Zone edu Domain Domains are divided in Zones manages a zone Less information overhead for s purdue.edu Zone Delegation Name tables change infrequently, but when they do, caching can result in the delivery of stale data. ¾ Clients are responsible for detecting this and for recovering Its design makes changes to the structure of the name space difficult. For example: ¾ merging previously separate domain trees under a new root ¾ moving sub-trees to a different part of the structure

6 DNS Resource Records Naming information are stored in the leafs in so-called Resource Records Type of record SOA A MX SRV NS CNAME PTR HINFO TXT Associated entity Zone Host Domain Domain Zone Node Host Host Any kind Description Holds information on the represented zone Contains an IP address of the host this node represents Refers to a mail server to handle mail addressed to this node Refers to a server handling a specific service Refers to a name server that implements the represented zone Symbolic link with the primary name of the represented node Contains the canonical name of a host Holds information on the host this node represents Contains any entity-specific information considered useful Example of Content Name Resolution in DNS Name Resolution in DNS DNS supports iterative and recursive name resolution Iterative resolution is the standard technique Recursive resolution is needed when the client only has limited access in a domain (security reasons) Iterative resolution can be made by a name server instead of the client's name resolver: client 1 4 NS1 2 NS2 3 NS3 Non-recursive server-controlled 1 client 5 NS1 2 4 NS2 3 NS3 Recursive server-controlled request Name Server Resolver reply request for address of girigiri.gbrmpa.gov.au reference to au request for address of girigiri.gbrmpa.gov.au reference to gov.au request for address of girigiri.gbrmpa.gov.au reference to gbrmpa.gov.au request for address of girigiri.gbrmpa.gov.au address of girigiri.gbrmpa.gov.au au gov.au gbrmpa.gov.au au gov nz edu sg sa ips gbrmpa A name server NS1 communicates with other name servers on behalf of a client

7 Global Name Service (GNS) GNS has more flexibility than DNS DNS was originally not designed for that large data volumes an early research project (1985) developed solutions for the problems of resource location, mail addresses and authentication: GNS ¾ consideration of large name spaces Directory and Discovery Service Directory service:- 'yellow pages' for the resources in a network Retrieves the set of names that satisfy a given description e.g. X.500, LDAP, MS Active Directory Services (DNS holds some descriptive data, but: the data is very incomplete DNS isn't organised to search it) ¾ restructuring name spaces Problem: scalability and performance of root node after merging several sub-trees Discovery service:- a directory service that also: is automatically updated as the network configuration changes meets the needs of clients in spontaneous networks discovers services required by a client (who may be mobile) within the current scope, for example, to find the most suitable printing service for image files after arriving at a hotel. Examples of discovery services: Jini discovery service, the 'service location protocol', the 'simple service discovery protocol', the 'secure discovery service'. Automatic registration of new services and automatic connection of new clients to the discovery service X.500 X.500 Database Entries OSI X Directory Service (by ITU/ISO) Attribute Abbr. Value a hierarchically-structured standard directory service designed for world-wide use ¾ accommodates resource descriptions in a standard form and their retrieval for any resource (online or offline) ¾ never fully deployed, but the standard forms the basis for LDAP, the Lightweight Directory Access Protocol, which is widely used Originally designed for descriptions of human beings, but can be applied to any type of 'resource' Country Locality Organization OrganizationalUnit CommonName Mail_Servers C L L OU CN -- NL Amsterdam Vrije Universiteit Math. & Comp. Sc. Main server , , FTP_Server Lightweight Directory Access Protocol, LDAP WWW_Server X.500 uses higher OSI layers for access operations, LDAP defines a simpler approach: direct access by using TCP/IP X.500 uses ASN.1 to describe resources, LDAP only needs a textual description LDAP not depends on X.500, each directory service can be used ¾ A X.500 directory entry using X.500 naming conventions. ¾ Similar to DNS resource records ¾ Collection of (attribute, value) pairs ¾ Collection of all directory entries: Directory Information Base ¾ Globally unique name for each entry

8 X.500 Directory Information Tree X.500 Alternative DIB Entry ¾Unique names by hierarchical structure ¾Globally unique name is sequence of identifiers in directory entry, e.g. /C=NL/O=Vrije Universiteit/OU=Math. & Comp. Sc. /CN=Main server Resulting tree: Directory Information Tree Attribute Country Locality Organization OrganizationalUnit CommonName Host_Name Host_Address Value NL Amsterdam Vrije Universiteit Math. & Comp. Sc. Main server star info Alice Flintstone, Departmental Staff, Department of Computer Science, University of Gormenghast, GB commonname Alice.L.Flintstone Alice.Flintstone Alice Flintstone A. Flintstone surname Flintstone telephonenumber uid alf mail roomnumber Z42 userclass Research Fellow X.500 Architecture X.500 Search Operations Implemented similar to name services like DNS DUA DSA DSA Adding functionality to a simple name service: more lookup operations Facilities are given for searching an entry by its attributes Provides more lookup operations (advanced search operations) Two different components: ¾ Directory User Agent (DUA) ¾ Directory Service Agent (DSA) DUA DUA DSA DSA DSA DSA Example: list all servers at Vrije Universiteit: answer=search("&(c=nl)(o=vrije Universiteit)(OU=*)(CN=Main Server)") Searching generally is an expensive operation: access several leaf nodes to get an answer, several DSAs have to be accessed Result: never really implemented, only LDAP as simpler version becomes a defacto standard in the Internet (e.g. Windows 2000) Naming information are distributed over several DSAs (like zones in DNS) DUAs are representing clients (like name resolver in DNS) One more approach: Trading Service, searching entries e.g. by given quality attributes (e.g. in CORBA)

9 admin Service Discovery - Jini Mobile client Lookup service 4. Use printing service 1. finance lookup service? Printing service admin Client Network 2. Here I am:... admin, finance Naming vs. Locating Entities ¾ Till now: resources with fixed locations (hierarchical, caching,...) ¾ Problem: some entity may change its location frequently ¾ Simple solution: record aliases for the new address or the new name ¾ But: efficiency, re-use of old names,... New approaches are necessary, e.g. identifiers for an resource Corporate infoservice Printing service finance 3. Request printing & receive proxy Lookup service Entity ID Jini services register their interfaces and descriptions with the Jini lookup services in their scope Clients find the Jini lookup services in their scope by IP multicast/broadcast Jini lookup service searches by attribute or by interface type The designers of Jini argue convincingly that this the only reliable way to do discovery a) Direct, single level mapping between names and addresses. b) T-level mapping using identities. Needs a location service to resolve identifiers Simple Solution Forwarding Pointers (1) Using Broadcast or Multicast ¾ Broadcast is typically offered in LANs ¾ Simple locating process: broadcast identifier and wait on a reply (principle used in the Internet protocol ARP [Address Resolution Protocol]) ¾ But: inefficient in large systems ¾ More efficient: using multicast for location ¾ But: you need to know the multicast group More popular approach for location: Forwarding Pointers Principle: A moving entity leaves behind a reference to the new location Client follows the chain of forwarding pointers But... ¾ Long chains makes the location process very expensive ¾ Intermediate nodes have to store all pointers as long as needed ¾ Broken links prohibit location old location new location Short chains and robust pointers are needed

10 Forwarding Pointers (2) Home-Based Approaches ¾ When an object moves it leaves behind a proxy having the new location reference ¾ Location is transparent for the client, request is forwarded along the chain ¾ Object sends back its new location to the caller, the forwarding pointer is redirected Popular approach for large-scale networks: home location principle of Mobile IP But: increase in communication latency, moving the home location? Hierarchical Approaches Information Stored in Nodes ¾ Extending the home-based approach to several layers ¾ Network is divided into domains, sub-domains,... (similar to DNS) ¾ Leaf domains: local area network, cell in a mobile telephone network,... ¾ An entity located in domain D is represented by a location record in directory node dir(d) ¾ Location records on higher hierarchies point to next sub-domain directory node Entities may have multiple addresses (e.g. replication) Higher-level node stores pointers to each location Scalability problem: root node has to store all information

11 Location Lookup Location Update Install a replicate in a new domain: new pointers have to be set Looking up a location in a hierarchically organized location service Client contacts directory node in its own domain Go up hierarchy to the first directory node holding the information 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. Similar operation: deletion of pointers Pointer Caches Invalidation of Pointer Caches Caching can be used to store locations of 'stable' nodes Location caching: inefficient lookup with each location change Pointer caching: Caching a reference to a directory node (dir(d)) of the lowest-level domain in which an entity (E) will reside most of the time. A cache entry that needs to be invalidated because it returns a non-local address, while such an address is available.

12 Scalability Issues Root directory node becomes bottleneck Solution: placing sub-nodes of a partitioned root across the network Spread sub-nodes uniformly; but new scalability problems: which node to give responsibility??? The Problem of Unreferenced Objects Problem with forwarding pointers: unreferenced object Garbage collection for remote objects: hidden from clients and objects itself How many proxies point to another one? Reference graph Solution: Reference Counting Simply count the references pointing to you Problem: unreliable communication ¾ Process P expects to get an acknowledgement when it increases the skeletons counter ¾ Acknowledgement can get lost ¾ P sends the increase message again Necessary to detect duplicates Reference Counting Another problem: copying a remote reference to another process a) Copying a reference to another process and incrementing the counter too late b) Solution by using acknowledgements One more problem: performance problems in large-scale systems by communication overhead

13 Advanced Referencing Counting Weighted reference counting: each object has A fixed total weight A partial weight, initialised with the total weight Creating a remote reference causes transmitting half the partial weight to the referencer Advanced Referencing Counting Copying a reference to P2 causes P1 in transmitting half the weight a) The initial assignment of weights in weighted reference counting b) Weight assignment when creating a new reference. Deleting a reference causes the remote object to subtract the weight of the referencer from its total weight When the total weight becomes zero, there are no more references Advanced Referencing Counting Problem: the partial weight of the remote object can become zero. What is with former objects which want to make a reference? Make use of indirections when partial weight reaches one Advanced Referencing Counting Alternative to the use of indirections: generation reference counting When copying the reference to P2, P1 creates a local skeleton with some total weight and the same partial weight Then transmitting half the partial weight to P2 Associate a generation and a copy counter with each referencing process Both counters are initialised with zero When copying a reference, the copy counter is increased; the new referencer becomes the next generation compared to the old one Skeleton maintains the numbers of outstanding copies for each generation; in case of a decrement request, the counter for the referencer's generation is decreased. The copies of the referencer is added to the next generation. If all generation entries are zero, there are no more references

14 And much simpler... Reference listing Skeleton keeps track of the proxies having a reference to it, i.e. it has a list of all these proxies (reference list) instead of a counter ¾ No problems with duplicated increments ¾ Easy to keep the list consistent in case of process failures ¾ Problem: copying a reference and deleting it too early (as in reference counting) ¾ Main drawback: bad scalability in case of many references Used in Java RMI Tracing-based Garbage Collection How can isolated referencer groups be located? ¾ Tracing all entities in a distributed system ¾ Removing all non-reachable entities ¾ Scalability problems! only consider groups of processes Initial marking of skeletons. Tracing in Groups (2) 1. Marking the skeletons Hard mark: reachable from a root object, a hard marked proxy, or an external object Soft mark: only reachable from inside the group 2. Propagating marks to proxies 3. Repeating these steps till no more change is made Tracing in Groups (3) If there are no more changes: deletion of soft-marked objects reduction of objects in groups after that: analysis of intergroup references on higher-level groups