1 / 86

LINF 2345 Naming

LINF 2345 Naming. Seif Haridi Peter Van Roy. Naming Entities. Names, identifiers, and addresses Name resolution Name space implementation Locating mobile entities Reclaiming references. Names, Identifiers, and Addresses. Naming.

forrest-riddle
Télécharger la présentation

LINF 2345 Naming

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. LINF 2345Naming Seif Haridi Peter Van Roy S. Haridi and P. Van Roy, LINF2345

  2. Naming Entities • Names, identifiers, and addresses • Name resolution • Name space implementation • Locating mobile entities • Reclaiming references S. Haridi and P. Van Roy, LINF2345

  3. Names, Identifiers,and Addresses S. Haridi and P. Van Roy, LINF2345

  4. Naming • A name is a string of bits or characters that is used to refer to an entity • To operate on an entity, we need to access it, which is done through a special kind of entity called an access point • The name of an access point is called an address • An address could be used as an entity’s name, but this is usually not done since it is convenient to have a more abstract way of referring to an entity (e.g., access points can change during an entity’s lifetime) • A location-independent name for an entity E is independent of the addresses of E’s access points S. Haridi and P. Van Roy, LINF2345

  5. Pure Names and Identifiers • Pure name • A name that has no meaning at all; it is just a random string • Pure names can be used for comparison only • Identifier: A name having the following properties • P1: An identifier refers to at most one entity • P2: An entity is referred to by at most one identifier • P3: An identifier always refers to the same entity (it is never reused) • For example, the name “John Smith” cannot be used as an identifier • A telephone number cannot be used as an identifier either, because it can be reassigned S. Haridi and P. Van Roy, LINF2345

  6. Identifiers • An identifier need not necessarily be a pure name, i.e., it may have content • Question: Can the content of an identifier ever change? S. Haridi and P. Van Roy, LINF2345

  7. Name SpaceHierarchical names • A name space is a labeled, directed graph with two kinds of nodes • A leaf node has no outgoing edges and represents a (named) entity • A directory node has outgoing edges that refer to other nodes • One node is the root of the graph • Only outgoing, no incoming edges S. Haridi and P. Van Roy, LINF2345

  8. Name Space • A leaf node represents a (named) entity • A directory node is an entity that refers to other nodes • Note: A directory node contains a (directory) table of (node identifier, edge label) pairs S. Haridi and P. Van Roy, LINF2345

  9. Name Space Contents • Path names, e.g., n0<home, steen, mbox> • Identifiers, e.g., n0, n1, … • Possibly also addresses (access points) S. Haridi and P. Van Roy, LINF2345

  10. Name Space Attributes • We can easily store all kinds of attributes in a node, describing aspects of the entity the node represents: • Type of the entity • An identifier for that entity • Address of the entity’s location • Nicknames • ... • Observation: Directory nodes can also have attributes, besides just storing a directory table with (edge label, node identifier) pairs S. Haridi and P. Van Roy, LINF2345

  11. Name Resolution S. Haridi and P. Van Roy, LINF2345

  12. Name Resolution • The process of looking up a name given its path name is called name resolution • Problem: To resolve a name we need an initial directory node • How do we find that initial node? • Closure mechanism: The mechanism to find the initial node from which to start name resolution S. Haridi and P. Van Roy, LINF2345

  13. Closure mechanism • The mechanism to find the initial node from which to start name resolution • www.cs.vu.nl: start at a DNS name server • /home/steen/mbox: start at the local NFS file server (possible recursive search) • 0031204447784: dial a phone number • 130.37.24.8: route to the VU’s Web server • Question: Why are closure mechanisms always implicit? • Observation: A closure mechanism may also determine how name resolution should proceed S. Haridi and P. Van Roy, LINF2345

  14. Name Linking • Hard link: What we have described so far as a path name: a name that is resolved by following a specific path in a naming graph from one node to another • Soft link: Allow a node to contain a (path) name of another node S. Haridi and P. Van Roy, LINF2345

  15. Soft Link • Soft link: Allow a node O to contain a (path) name of another node • First resolve O’s name (leading to O) • Read the content of O, yielding name • Name resolution continues with name • The name resolution process determines that we read the content of a node, in particular, the name in the other node that we need to go to • One way or the other, we know where and how to start name resolution given name S. Haridi and P. Van Roy, LINF2345

  16. Name Linking Observation: Node n5 has only one name S. Haridi and P. Van Roy, LINF2345

  17. Merging Name Spaces • Problem: We have different name spaces that we wish to access from any given name space S. Haridi and P. Van Roy, LINF2345

  18. Merging Name SpacesSolution 1 • Introduce a naming scheme by which path names of different name spaces are simply concatenated (URLs) S. Haridi and P. Van Roy, LINF2345

  19. Merging Name SpacesSolution 2 • Introduce nodes that contain the name of a node in a “foreign” name space, along with the information how to select the initial context in that foreign name space (Jade file system) S. Haridi and P. Van Roy, LINF2345

  20. Merging Name SpacesSolution 2 S. Haridi and P. Van Roy, LINF2345

  21. Merging Name SpacesSolution 2 • Introduce nodes that contain the name of a node in a “foreign” name space, along with the information how to select the initial context in that foreign name space • Mount point: (Directory) node in naming graph that refers to other naming graph • Mounting point: (Directory) node in other naming graph that is referred to S. Haridi and P. Van Roy, LINF2345

  22. Merging Name SpacesSolution 2 Mount Point Mounting Point S. Haridi and P. Van Roy, LINF2345

  23. Merging Name SpacesSolution 3 • Use only full pathnames, in which the starting context is explicitly identified • Merge by adding a new root node (used in DEC’s Global Name Space) • Note: In principle, you always have to start in the new root S. Haridi and P. Van Roy, LINF2345

  24. Merging Name SpacesSolution 3: New Root Node S. Haridi and P. Van Roy, LINF2345

  25. Name SpaceImplementation S. Haridi and P. Van Roy, LINF2345

  26. Name Space Implementation • Distribute the name resolution process as well as name space management across multiple machines, by distributing nodes of the naming graph • Consider a hierarchical naming graph and distinguish three levels • Global level • Administrational level • Managerial level S. Haridi and P. Van Roy, LINF2345

  27. Name Space Implementation • Global level • Consists of the high-level directory nodes • Main aspect is that these directory nodes have to be jointly managed by different administrations • Administrational level • Contains mid-level directory nodes that can be grouped in such a way that each group can be assigned to a separate administration • Managerial level • Consists of low-level directory nodes within a single administration • Main issue is effectively mapping directory nodes to local name servers S. Haridi and P. Van Roy, LINF2345

  28. Name Space Implementation S. Haridi and P. Van Roy, LINF2345

  29. Name Space Implementation S. Haridi and P. Van Roy, LINF2345

  30. Iterative Name Resolution • resolve(dir,[name1,...,nameK]) is sent to Server0 responsible for dir • Server0 resolves resolve(dir,name1)dir1, returning the identification (address) of Server1, which stores dir1 • Client sends resolve(dir1,[name2,...,nameK]) to Server1 • etc … S. Haridi and P. Van Roy, LINF2345

  31. Iterative Name Resolution S. Haridi and P. Van Roy, LINF2345

  32. Recursive Name Resolution • resolve(dir,[name1,...,nameK]) is sent to Server0 responsible for dir • Server0 resolves resolve(dir,name1)dir1, and sends resolve(dir1,[name2,...,nameK]) to Server1 • Server0 waits for the result from Server1, and returns it to the client S. Haridi and P. Van Roy, LINF2345

  33. Recursive Name Resolution S. Haridi and P. Van Roy, LINF2345

  34. Caching in Recursive Name Resolution S. Haridi and P. Van Roy, LINF2345

  35. Scalability IssuesSize Scalability • We need to ensure that servers can handle a large number of requests per time unit high-level servers are in big trouble. • Solution • Assume (at least at global and administrational level) that content of nodes hardly ever changes • In that case, we can apply extensive replication by mapping nodes to multiple servers, and start name resolution at the nearest server S. Haridi and P. Van Roy, LINF2345

  36. Scalability IssuesSize Scalability • Observation: An important attribute of many nodes is the address where the represented entity can be contacted • Replicating nodes makes large-scale traditional name servers unsuitable for locating mobile entities (cf. next section) S. Haridi and P. Van Roy, LINF2345

  37. Scalability IssuesGeographical Scalability • We need to ensure that the name resolution process scales across large geographical distances • Problem: By mapping nodes to servers that (the servers) may, in principle, be located anywhere, we introduce an implicit location dependency in our naming scheme • Solution: No general one available yet S. Haridi and P. Van Roy, LINF2345

  38. LocatingMobile Entities S. Haridi and P. Van Roy, LINF2345

  39. Locating Mobile Entities • Naming versus locating entities • Simple solutions • Home-based approaches • Hierarchical approaches S. Haridi and P. Van Roy, LINF2345

  40. Naming & Locating Entities • Location service: Solely aimed at providing the addresses of the current locations of entities • Assumption: Entities are mobile, so that their current address may change frequently • Naming service: Aimed at providing the content of nodes in a name space, given a (compound) name • Content: Anything that depends on the type of node, in our context it is a set of (attribute, value) pairs S. Haridi and P. Van Roy, LINF2345

  41. Naming & Locating Entities • Assumption: Node contents at global and administrational level are relatively stable for scalability reasons. • Observation: If a traditional naming service is used to locate entities, we also have to assume that node contents at the managerial level are stable, as we can use only names as identifiers (think of Web pages) S. Haridi and P. Van Roy, LINF2345

  42. Naming & Locating Entities • Problem: It is not realistic to assume stable node contents down to the local naming level • Solution: Decouple naming from locating entities S. Haridi and P. Van Roy, LINF2345

  43. Naming & Locating Entities S. Haridi and P. Van Roy, LINF2345

  44. Naming & Locating Entities • Name: Any name in a traditional naming space • Entity ID: A true identifier • Address: Provides all information necessary to contact an entity • Observation: An entity’s name is now completely independent from its location • Question: What may be a typical address? S. Haridi and P. Van Roy, LINF2345

  45. Simple Solutionsfor Locating Entities • Broadcasting: Simply broadcast the ID, requesting the entity to return its current address • Can never scale beyond local-area networks • Requires all processes to listen to incoming location requests S. Haridi and P. Van Roy, LINF2345

  46. Simple Solutionsfor Locating Entities • Forwarding pointers: Each time an entity moves, it leaves behind a pointer telling where it has gone to • Dereferencing can be made entirely transparent to clients by simply following the chain of pointers • Update a client’s reference as soon as present location has been found • Geographical scalability problems: • Long chains are not fault tolerant • Increased network latency at dereferencing • Essential to have separate chain reduction mechanisms S. Haridi and P. Van Roy, LINF2345

  47. Home-Based ApproachesMobile IP • Single-tiered scheme • Let a home keep track of where the entity is • An entity’s home address is registered at a naming service • The home registers the foreign address of the entity • Clients always contact the home first, and then continue with the foreign location S. Haridi and P. Van Roy, LINF2345

  48. Home-Based Approaches S. Haridi and P. Van Roy, LINF2345

  49. Home-Based ApproachesTwo Tiered Scheme (Mobile Telephony) • Keep track of visiting entities • Check local visitor register first • Fall back to home location if local lookup fails S. Haridi and P. Van Roy, LINF2345

  50. Home-Based ApproachesProblems • The home address has to be supported as long as the entity lives (Home Location Registry) • 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 move” problem? S. Haridi and P. Van Roy, LINF2345

More Related