Addressing, Naming and Routing

In order to discuss access and location transparency, we need to understand how objects are named, addressed and reached within a distributed system. The classic definition of these three terms is due to Shoch[#shoch##1#]: In a distributed system, access transparency means that we must <#251#> hide<#251#> the distribution from the application somehow. However, often hiding only goes so far as the access mechanism (e.g. remote procedural], and the distribution may be apparent from the <#252#> name<#252#>. Examples of distribution being obvious from the name are common in distributed programs such as electronic mail and some distributed file systems [for example, names for remote files in many PC network file sharing systems include the remote fileserver name]. However, in a distributed system many objects may have the same name (sometimes deliberately as in groups, sometimes by accident); an object may have many names. Choosing unique names in a large distributed is a hard problem, which some argue it doesn't even make sense to try to solve. To access an object, we must derive first an address, and then a route to that address, from its name. Addressing and routing are the mechanisms that hide the distribution from the application. Names often become addresses and vice versa as you move through different levels of abstraction in the system: as an example, here are the mappings from name to address at the application level and network level, and then from name to address from the inernet level to the local area network level: verbatim4 <#516#>#tex2html_wrap3804#<#516#> Names, Addresses and Routes are so often confused that one might be forgiven for saying <#254#> One person's name is another person's address<#254#>. The reason for the confusion is partly the multiplicity of contexts these words are used in, but also partly because although the design requirements are clear, the functions are often mixed up in implementation, or in presentation to a human user. In the author's experience, the easiest way to understand the model given here is to map it to one particular implementation (be it the postal service, the telephone system of the Internet or another) and thereafter think of all new systems encountered in terms of that! <#517#>#tex2html_wrap3806#<#517#>