1 / 28

Naming in Distributed Systems

Naming in Distributed Systems. Outline. Introduction Some basic Concepts INS :) Yet another naming Scheme. Why Name?. Convenience in Accessing/Sharing Objects (Files) Fundamental concept in Communication (mailboxes, remote nodes). What does Naming get us?.

xenia
Download Presentation

Naming in 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. Naming in Distributed Systems

  2. Outline • Introduction • Some basic Concepts • INS :) • Yet another naming Scheme.

  3. Why Name? Convenience in Accessing/Sharing Objects (Files) Fundamental concept in Communication (mailboxes, remote nodes)

  4. What does Naming get us? • Mapping between names->objects • Provide info on those objects • Locate/discover objects and their attributes Thus it directly affects : • Sharing, migration, replication, security

  5. Names • Most definitions are inadequate. • ISO : It is an identifier that denotes an object. Classification • Non-Ambiguous. 1->N (Name->Object) • Non-Unique. N->1 • Global.

  6. Names, Addresses And Routes • Name specifies WHAT, address WHERE, routes HOW to get there. • Each is a tighter binding of information. • System names / Communication names. • Name is usually user-friendly. Naming facility translates names-> addresses-> routes. Routing is part of naming!

  7. Name Structure • Flat : No internal structure. • Partitioned : Usually hierarchical and have a naming context. • Descriptive : Attribute Based. Partitioned name is subclass. Non-unique Names. Std. Structure & Semantics needed.

  8. Naming Context/Domain • A context can be defined as the environment in which a name is valid. (Global names have no context.) • Helps partition the name space. • Implicit Context : Relative naming conventions.

  9. Naming schemes • Hierarchical : • Extensible/scalable. • Goes with logical view of the system. • Implicit context -> smaller names. • Configuration is (usually) not simple.

  10. Naming Schemes (cont’d) • Descriptive : • Supports ‘services’. • Scalable. • Easily supports fault-tolerance, group communication. • Processing overhead is usually large.

  11. Naming Schemes (cont’d) • Flat : • No internal structure. • Names remain same even if object moves. • Easily hashed and stored (no processing overhead) : efficient. • Easier to implement? • Not scalable.

  12. Factors in Designing Naming Facility • Ease of Name generation. • Location Transparency: Dynamic binding of names->addresses. Object mobility. • Two levels of identification : user-friendly, machine-friendly. • Efficient : Delay, #messages exchanged must be minimum.

  13. Support for 1->N mapping between names & addresses : • Fault Tolerance • Group Communication.

  14. INS • LCS, MIT. 1999 • Part of self-organizing adaptive networks research.

  15. Motivation • How to adapt to dynamicity in networks seamlessly - mobility of devices and services. • Dynamic resource discovery and service location. • Software and service mgmt cost > HW • E.g. : good ol’ printer, finding least loaded server, etc.

  16. Design Goals • Expressiveness : in finding/discovering devices/services. • Responsiveness : adapt quickly to mobility. • Robustness : Name service failures, inconsistent state. • Easy Configuration : minimal manual intervention, dynamic load distribution.

  17. What is meant by INS • Describe ‘what’ (intent) to look for, not where. • Intentional names implemented using name-specifiers :- Hierarchy of attributes and values. • Message headers contain name-specifiers not IP addresses.

  18. INS Architecture • INRs form overlay network. • Services register with the INRs (periodic advertisement) • Clients send messages to INRs. • Early/Late binding. • Intentional anycast/multicast.

  19. INR boot-up • DSR (Domain Space Resolver) maintains list of active/candidate INRs. • New INR : ping every other INR. Establish neighbour relation. • Spanning tree of INRs.

  20. Service Registration • Soft State, Soft State, Soft State! :- robustness. • Periodically advertise intentional names to INR. • INR relays names to other INRs periodically :- All INRs know all names!

  21. Client side • Intentional Anycast : Send to any server satisfying request. • Intentional Multicast : All servers satisfying request • Early Binding : Similar to DNS. • Late Binding : Message routing at name resolution time.

  22. Load Balancing, Scaling • Spawn INRs on candidates. Kill if below threshold. • Divide name-space : • Handle only part of name space. • Cache popular ones. • Refer to root (DSR) otherwise.

  23. Naming & Addressing withoutUnique Identifiers • Sony CSL. • Muse operating system.

  24. Motivation • Scalability. Ability to generate unique ids regardless how how big system grows. • Mobility : Of hosts and dynamically adapting to it.

  25. Design Goals • Uniqueness : One name should only represent one object. • Location transparency. • Scalability • Short repstn. to logically nearby objects. • Availability and fault tolerance of name service.

  26. Assumptions • Ultra large scale : broadcast impossible. • Communication with distant objects is rare compared to local ones. • Local naming contexts with hierarchical structure.

  27. Design • One root naming context • Relative representation. • OIDs, OADs, LIDs, LADs : • Format of OID. • Interpretation of OID • Translation of OID/OAD • Message Passing • Object Migration

  28. Close

More Related