1 / 35

Distributed Systems

Distributed Systems. Name Services. Dr. Sunny Jeong. spjeong@uic.edu.hk Mr. Jerry Li. jerryli@uic.edu.hk With Thanks to Prof. G. Coulouris, Prof. A.S. Tanenbaum and Prof. S.C Joo. Overview. Naming concepts name space, contexts, hierarchies The service function and goals

hanne
Download Presentation

Distributed Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Distributed Systems Name Services Dr. Sunny Jeong. spjeong@uic.edu.hk Mr. Jerry Li. jerryli@uic.edu.hk With Thanks to Prof. G. Coulouris, Prof. A.S. Tanenbaum and Prof. S.C Joo

  2. Overview • Naming concepts • name space, contexts, hierarchies • The service • function and goals • name resolution • replication and caching • Examples • Domain Name Service (DNS) • Jini discovery service • Global directory Service • X.500 directory service

  3. Distributed Service

  4. Naming concepts Names = strings used to identify objects (files, computers, people, processes, objects). • Textual names (human readable) • used to identify individual services, people • email address: xxx@uic.edu.uk • URI(Uniform Resource Identifier): www.cdk3.net • URL(Uniform Resource Locator) • URI’s particular type • URN(Uniform Resource Name) • URI’s other particular type • URC(Uniform Resource Characteristics or Citations) • URN’s subset • Groups of objects • multicast address (e.g. IP Multicast, group of hosts) • broadcast address (e.g. Ethernet, all hosts)

  5. Naming concepts -ctd • Numeric addresses (location dependent in Internet, now) • 147.188.195.11, • Object identifiers( = object handle) • pure names (=bit patterns), usually numeric and large[Needham, 1993] • never reused (include timestamp) • location independent • used for identification purposes =>No real distinction between names and addresses. =>Both must be looked up to obtain lower-level data (= name resolution).

  6. Examples of name services • DNS (=Domain Name Service) • maps domain names to IP addresses • Jini discovery service • looks up objects according to attributes(service) • GNS (=Global Name Service) • GNS directory tree • maps global names to their attributes (Resource Location, Mail address. Authentication) • scalable, can handle change • X.500 directory service (attribute service) • maps person’s name to attributes (email address, phone number)

  7. URL http://www.cdk3.net:8888/WebExamples/earth.html DNS lookup Resource ID (IP number, port number, pathname) 55.55.55.55 8888 WebExamples/earth.html Web server Network address file 2:60:8c:2:b0:5a Socket DNS names & look-ups

  8. Name space • Name space = collection of all valid names recognized by a service with • a syntax for specifying names, and rules for resolving names (left to right, etc) • Naming context = maps a name onto primitive attributes directly, or onto another context and derived name (usually by prefixing) • telephone No. : country, area, number • Internet host names : contexts = domains • Unix file system : contexts = directories

  9. Name space -ctd • Name binding • an association between a name and an object • names bound to attributes, one of which may be address • Naming domain • has authority that assigns names to objects within a name space or context • object may be registered more than once within context( replication) • Multiple names • alias (alternative name for an object) • symbolic name (alternative name which maps to a path name in the name space)

  10. Hierarchic name spaces • Sequence of name tokens resolved in different context • syntax: name token (text string) + delimiter • DNS: cs.bham.ac.uk • Unix: /usr/bin • Structure reflects organizational structure • name changes if object migrates • names relative to context or absolute • local contexts managed in a distributed fashion • Examples • domain names, Unix file system, etc

  11. Flat name spaces • Single global context and naming authority for all names • computer serial number • Ethernet address • remote object reference (IP address, port, time, object number, interface id) • Names (are) not meaningful • difficult to resolve (no tree hierarchy) • easy to create • easy to ensure uniqueness (timestamps)

  12. Name Resolution • Iteratively, presents name to a naming context, • start with initial naming context • repeat as long as contexts+derived names are returned • aliases introduce cycles • Two solution for no cycle • abandon after threshold No. of resolutions • ensure no cycles by administrator • Replication • used for improved fault-tolerance on large services (more than one server, cf DNS) • may need navigation, i.e. accessing several servers

  13. NS2 2 Name 1 NS1 servers Client 3 NS3 - Database partitioned into servers according to its domain. - A client iteratively contacts name servers NS1–NS3 in order to resolve a name. - Servers returns attributes if it knows name, otherwise suggests another server. Iterative navigation

  14. Navigation methods • Multicast navigation • client multicasts name to be resolved • server who knows name responds with attributes • problem: what if name unbound? • Non-recursive server controlled • any name server can be chosen by the client • chosen server multicast/iteratively calls other peer servers • Recursive server controlled • each iteration through a single server • calls continue recursively until resolution

  15. NS2 NS2 2 2 4 3 1 1 NS1 NS1 client client 3 5 4 NS3 NS3 Non-recursive Recursive server-controlled server-controlled - A name server NS1 communicates with other name servers on behalf of a client. Server controlled navigation

  16. Replication & Caching Replicate some directories for performance & availability. • Updates • write to single master, master propagates updates • write to any replica: later merge updates (timestamps) • weak consistency (some entries out of date) • Look-ups • try any local server: go to root and then down the tree • Caching • names & addresses of recently used objects

  17. Internet Domain Name Service (DNS) • Used mainly for host names and email addresses • Extensible number of fields, separated by dot(.) • gromit.cs.bham.ac.uk • Host name resolution • resolves host name into IP address • Mail host location • to resolve xxx@cs.bham.ac.uk, query DNS with domain name cs.bham.ac.uk and type ‘mail’ • returns list of mail hosts, marked with preference value • Reverse look-up (Maps IP address to domain name)

  18. DNS name servers • Resource record holds • domain name for which record applies • time to live: initial validity time for cached entries • type (IP address, mail server, name server, alias) • value fields • Replicated and partitioned information • update master server • Secondary servers • periodically download from master and save in cache • hold addresses of one or more masters up the tree • recursive look-up

  19. a.root-servers.net Note: Name server names are in italics, and the corresponding domains are in parentheses. (root) Arrows denote name server entries uk purdue.edu ns1.nic.uk (uk) yahoo.com ns.purdue.edu (purdue.edu) co.uk ns0.ja.net ac.uk (ac.uk) * .purdue.edu ic.ac.uk qmw.ac.uk *.dcs.qmw.ac.uk dcs.qmw.ac.uk *.ic.ac.uk *.qmw.ac.uk alpha.qmw.ac.uk dns0-doc.ic.ac.uk dns0.dcs.qmw.ac.uk (qmw.ac.uk) (dcs.qmw.ac.uk) (ic.ac.uk) DNS name servers ctd

  20. a.root-servers.net (root) uk purdue.edu ns1.nic.uk yahoo.com .... (uk) ns.purdue.edu (purdue.edu) co.uk ac.uk... ns0.ja.net (ac.uk) * .purdue.edu ic.ac.uk qmw.ac.uk... IP: alpha.qmw.ac.uk alpha.qmw.ac.uk dns0.dcs.qmw.ac.uk dns0-doc.ic.ac.uk (qmw.ac.uk) (dcs.qmw.ac.uk) (ic.ac.uk) IP:jeans-pc.dcs.qmw.ac.uk IP:ns0.ja.net 4 3 2 1 dcs.qmw.ac.uk *.dcs.qmw.ac.uk *.ic.ac.uk *.qmw.ac.uk jeans-pc.dcs.qmw.ac.uk ? IP:dns0.dcs.qmw.ac.uk DNS in typical operation Without caching client.ic.ac.uk *

  21. DNS summary • DNS • relatively short average response time for look-ups • limited variety of data • infrequent changes in system • inconsistency of data possible (stale data may continue to be used) • Problems (resolved in GNS) • rigid structure of the name space • lack of customization of name space to local needs

  22. Directory and discovery services • Directory service • stores collections of bindings between names and attributes • provides look-up according to attributes (match all) • examples • Microsoft Active Directory Services, X.500 • Discovery service • directory service that registers the services in a spontaneous networking environment • clients & services change dynamically • Example • Jini discovery

  23. Jini discovery service • Function • to enable users to access services (printing etc.) from laptops while away, without their involvement • laptops look-up the services • services tell system of their existence and attributes • Components • lookup service (registers and stores information about services) • Jini services (provide objects and attributes for the service) • Jini clients (request services that match requirements) • Java/JVM based, • uses RMI plus download code

  24. admin Printing Client service 1. in ‘finance’ group lookup service? admin Client Lookup service Network 2.Here I am: ..... 4.Use printing service ( by RMI) admin, finance Lookup 3.Request service Corporate Printing printing infoservice service finance Service discovery in Jini

  25. Jini – How to works • How it works • services and clients join Jini dynamically • services have leases, which they have to renew periodically every t time units • look-up registers services (e.g. printer(name), what type(attributes), etc) • on entering, clients/services send request to multicast address • look-up services listen to such requests, and reply with unicast address of service (e.g. printer), and then, client contacts the service directly via RMI

  26. Global Name Service • GNS • DEC system research center[1986] • providing facilities(resource location, mail addressing, authentication) • The Global Name Service • Use of caching essential renders it extremely difficult to maintain complete consistency between all copies of a database entry • The cache consistency strategy adopted • A naming database that is composed of a tree of directories holding names and values • Names in GNS • directory name, value name(EC/UK/AC/QMW, Peter.Smith/password) • the first part identifies a directory, second refers to a value tree, or some portion of a value tree

  27. DI: 599 (EC) DI:633 (WORLD) UK FR DI: 543 DI: 574 Well-known directories: #599 = #633/EC AC NORTH AMERICA EC DI: 437 #642 = #633/NORTH AMERICA DI: 599 DI:642 QMW DI: 322 CANADA Peter.Smith US UK FR DI: 543 DI: 574 DI: 732 DI: 457 password mailboxes Alpha Beta Gamma GNS Directory tree GNS directory and value tree for Peter.Smith Merging trees under a new root(next page)

  28. DI: 633 (WORLD) Well-known directories: #599 = #633/EC EC NORTH AMERICA #642 = #633/NORTH AMERICA DI: 599 DI: 642 US US CANADA UK FR DI: 457 DI: 543 DI: 574 DI: 732 #633/EC/US GNS Directory Restructuring symbolic link Restructuring the directory

  29. GNS Discussion • Discussion of GNS • descended form Grapevine & Clearinghouse[1982] • successful naming systems developed primarily for the purposes of mail delivery by the Xerox Corporation • scalability and re-configurability • adopted for merging and moving directory trees results in a requirement for a database that must be replicated at every node • in a large-scale network, reconfigurations may occur at any level

  30. DUA DSA DSA DSA DUA DSA DSA DUA DSA X.500 Directory Service • Directory service • providing attributed-based name service • using the existing name service together • CCITT & ISO standard organizations • called the Directory Information Tree(DIT) • Directory Information Base(DIB) • X.500 Architecture • Client : Directory User Agent • Server: Directory Service Agent

  31. X.500 Service (root) ... France (country) Great Britain (country) Greece (country) ... ... BT Plc (organization) University of Gormenghast (organization) ... Computing Service (organizationalUnit) ... Department of Computer Science (organizationalUnit) Engineering Department (organizationalUnit) ... Departmental Staff (organizationalUnit) ... ely (applicationProcess) Research Students (organizationalUnit) ... ... ... Alice Flintstone (person) Pat King (person) James Healey (person) Janet Papworth (person) ... X.500 Directory Information Tree(DIT)

  32. info Alice Flintstone, Departmental Staff, Department of Computer Science, University of Gormenghast, GB commonName uid Alice.L.Flintstone alf Alice.Flintstone Alice Flintstone mail A. Flintstone alf@dcs.gormenghast.ac.uk surname Alice.Flintstone@dcs.gormenghast.ac.uk Flintstone roomNumber Z42 telephoneNumber +44 986 33 4604 userClass Research Fellow X.500 Directory Information Base(DIB)

  33. X.500 Directory Information Base(DIB) • Functions of Directory access request • read : a request resembles the lookup access defined in DNS model • search : attribute-based access request • Administration and updating of the DIB • DSA(Directory Service Agent) interface includes the following operations • adding, deleting and modifying entries • DIB • if DIB is partitioned, with the expectation that each organization will provide at least one server holding the details of the entities in that organization • Developed at University College, London(QUIPU) • both caching and replication are performed at the level of individual DIB entries, and at the level of collections of entries descended from the same node • values may become inconsistent after an update, and the time interval in which the consistency is restored may be several minutes • Discussion of X.500 • the implementation and application of X.500 is at a pilot stage(1994)

  34. Lightweight Directory Access Protocol(LDAP) • One of Directory Access protocol(DAP) for X.500 • DAP works on OSI stack and requiring lots of computing resources • LDAP works on TCP/IP stack and enable users access X.500 directory x.500 OSI LDAP Application TCP IP IP Physical media Network

  35. Summary • Name services • Store(= register) names and their attributes of objects, provide look-up • Requirements • handle very large name spaces, long lifetime • high availability, fault tolerance • Design issues • structure of the name space (syntax, resolution rules, is it changing over time?) • distribution across servers, navigation • replication & caching • Case studies • Domain Name Service (DNS) ( domain name  IP) • Jini discovery service( object  attribute) • Global Directory Service( global name attributes (resource location…)) • X.500 directory service(person’s name to attributes (email address, phone number))

More Related