Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
45
Chapter 3: Naming
Naming vs. Locating Entities
a) Direct, single level mapping between names and addresses
b) Two-level mapping using identifiers. Needs a location service to resolve identifiers
Till now: resources with fixed locations (hierarchical, caching, ...)
Problem: some entity may change its location frequently
Simple solution: record aliases for the new address or the new name
But: efficiency, re-use of old names, ...
New approaches are necessary, e.g. identifiers for an resource
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
46
Chapter 3: Naming
Simple Solution for a Location Service
Using Broadcast or Multicast
Broadcast is typically offered in LANs
Simple locating process: broadcast identifier and wait on a reply (principle used in ARP)
But: inefficient in large systems
More efficient: using multicast for location
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
47
Chapter 3: Naming
Forwarding Pointers (1)
More popular approach for location:
Forwarding Pointers
Principle:
• A moving entity leaves behind a reference to the new location
• Client follows the chain of forwarding pointers
But...
Long chains make the location process very expensive
Intermediate nodes have to store all pointers as long as needed
Broken links prohibit location
Short chains and robust pointers are needed
old location
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
48
Chapter 3: Naming
Forwarding Pointers (2)
When an object moves it leaves behind a proxy having the new location reference
Location is transparent for the client, request is forwarded along the chain
Object sends back its new location to the caller, the forwarding pointer is redirected
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
49
Chapter 3: Naming
Home-Based Approaches
• Popular approach for large-scale networks: home location
• Similar principle as used in Mobile IP
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
50
Chapter 3: Naming
Hierarchical Approaches
Extending the home-based approach to several layers
Network is divided into domains, sub-domains, ... (similar to DNS)
Leaf domains: local area network, cell in a mobile telephone network, ...
An entity located in domain D is represented by a location record in directory node dir(D)
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
51
Chapter 3: Naming
Information Stored in Nodes
• Entities may have multiple addresses (e.g. replication) • Higher-level node stores pointers to each location
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
52
Chapter 3: Naming
Location Lookup
• Looking up a location in a hierarchically organized location service • Client contacts directory node in its own domain
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
53
Chapter 3: Naming
Location Update
a) An insert request is forwarded to the first node that knows about entity E. b) A chain of forwarding pointers to the leaf node is created.
Install a replicate in a new domain: new pointers have to be set
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
54
Chapter 3: Naming
Pointer Caches
• Caching can be used to store locations of 'stable' nodes
• Location caching: inefficient lookup with each location change
• Pointer caching: Caching a reference to a directory node (dir(D)) of the lowest-level domain in which an entity (E) will reside most of the time.
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
55
Chapter 3: Naming
Invalidation of Pointer Caches
• A cache entry that needs to be invalidated because it returns a non-local address, while such an address is available.
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
56
Chapter 3: Naming
Scalability Issues
• Root directory node becomes bottleneck
• Solution: placing sub-nodes of a partitioned root across the network
• Spread sub-nodes uniformly; but… new scalability problems: which node to give responsibility???
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
57
Chapter 3: Naming
The Problem of Unreferenced Objects
• Problem with forwarding pointers: unreferenced object
• Garbage collection for remote objects: hidden from clients and objects itself • How many proxies point to another one?
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
58
Chapter 3: Naming
Solution: Reference Counting
• Simply count the references pointing to you • Problem: unreliable communication
Process P expects to get an acknowledgement when it increases the skeletons counter
Acknowledgement can get lost
P sends the increase message again • Necessary to detect duplicates
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
59
Chapter 3: Naming
Reference Counting
a) Copying a reference to another process and incrementing the counter too late b) Solution by using acknowledgements
Another problem: copying a remote reference to another process
One more problem: performance problems in large-scale systems by communication
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
60
Chapter 3: Naming
Advanced Referencing Counting
a) The initial assignment of weights in weighted reference counting b) Weight assignment when creating a new reference.
Weighted reference counting: each object has • A fixed total weight
• A partial weight, initialised with the total weight
Creating a remote reference causes transmitting half the partial weight to the referencer
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
61
Chapter 3: Naming
Weighted Referencing Counting
• Copying a reference to P2 causes P1 in transmitting half the weight
• Deleting a reference causes the remote object to subtract the weight of the referencer from its total weight
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
62
Chapter 3: Naming
Weighted Referencing Counting
• Problem: the partial weight of the remote object can become zero. What is with former objects which want to make a reference?
• Make use of indirections when partial weight reaches one
• When copying the reference to P2, P1 creates a local skeleton with some total weight and the same partial weight
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
63
Chapter 3: Naming
Generation Referencing Counting
• Alternative to the use of indirections: generation reference counting
• Associate a generation and a copy counter with each referencing process • Both counters are initialised with zero
• When copying a reference, the copy counter is increased; the new referencer becomes the next generation compared to the old one
• Skeleton maintains the numbers of outstanding copies for each generation; in case of a decrement request, the counter for the referencer's generation is decreased. The copies of the referencer is added to the next generation. If all generation entries are zero, there are no more references
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
64
Chapter 3: Naming
And much simpler...
Reference listing
• Skeleton keeps track of the proxies having a reference to it, i.e. it has a list of all these proxies (reference list) instead of a counter
No problems with duplicated increments
Easy to keep the list consistent in case of process failures
Problem: copying a reference and deleting it too early (as in reference counting)
Main drawback: bad scalability in case of many references • Used in Java RMI
Lehrstuhl für Informatik 4
Kommunikation und verteilte Systeme
65
Chapter 3: Naming
Conclusion
Different concepts:
• Naming Services for mapping of logical names to addresses
• Directory Services for searching addresses by describing the needed object • Discovery Services as a name database in “dynamic” networks
• Location Services for supporting moving objects
• Some close relations to file systems and reference counting What is the best concept?
