Naming. Chapter 4. Naming. Names are used to share resources, to uniquely identify entities, or to refer to locations. Name resolution is used for a process to access the named entity. Three issues are covered in this chapter:
PowerPoint Slideshow about ' Naming' - argus
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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
A name space forms the heart of a naming service. A naming service is implemented by name server. In distributed systems, it is necessary to 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: Consists of the highlevel directory nodes. Main aspect is that these directory nodes have to be jointly managed by different administrations
Administrational level: Contains midlevel directory nodes that can be grouped in such a way that each group can be assigned to a separate administration.
Managerial level: Consists of lowlevel directory nodes within a single administration. Main issue is effectively mapping directory nodes to local name servers.
Each client has access to a local name resolver, which is responsible for ensuring that the name resolution process is carried out.
There are two ways to implement name resolution:
In iterative name resolution, a name resolver hands over the complete name to the root name server, returning each intermediate result back to the client’s name resolver. The final name resolver responds to the client the final resolution.
In recursive name resolution, a root name server recursively passes the result to the next-level name server. The root name server responds to the client the final resolution..
Providing an X.500 directory allows an organization to make itself and selected members known on the Internet.
Two of the largest directory service providers are InterNIC, the organization that supervises domain name registration in the U.S., and ESnet, which maintains X.500 data for all the U.S. national laboratories.
ESNet and similar providers also provide access to looking up names in the global directory, using a number of different user interfaces including designated Web sites, whois, and finger.
These organizations also provide assistance to organizations that are creating their own Directory Information Tree (DIT).
If the node knows about the entity, follow downward pointer, otherwise go one level up.
Upward lookup always stops at the node that stores a location record for the entity.
If a mobile entity moves regularly within a domain, it is effective to cache a reference to the directory node. In this case, it makes sense to start a lookup at that directory node. This approach is referred as a pointer caching.
Storing a location record for each entity is not a problem. The problem is we need to ensure that servers can handle a large number of requests per time unit highlevel 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.
Observation: An important attribute of many nodes is the address where the represented entity can be contacted. Replicating nodes makes largescale traditional name servers unsuitable for locating mobile entities.
We have to ensure that lookup operations generally proceed monotonically in the direction of where we'll find an address:
If entity E generally resides in California, we should not let a root subnode located in France store E 's contact record.
Unfortunately, subnode placement is not that easy, and only a few tentative solutions are known.
We need to ensure that the name resolution process scales across large geographical distances.
By mapping nodes to servers that may be located anywhere, we introduce an implicit location dependency in our naming scheme (e.g. A domain E is mapped in Finland and moved to California. A request to E first contact Finland.) .
Deciding which subnodes should handle which entities remain an open question.