Distributed Systems: Naming Continued

1
Distributed SystemsNaming (Continued)

• CS 654Lecture 12October 25, 2006

2
Why Is This Any Better?

• Lets play Devils Advocate and compare this to
  straightforward solutions.
• Exploits locality
• Search expands in a ring.
• As an entity moves, it usually is a local
  operation.

3
Caching

• How effective is caching addresses?
• Depends on degree of mobility.
• If very mobile, what can we do to help?
• If D is the smallest domain that E moves around
  in, can cache dir(D).
• Called pointer caching.

4
Pointer Caches

• Caching a reference to a directory node of the
  lowest-level domain in which an entity will
  reside most of the time.

5
Invalidating

• A cache entry that needs to be invalidated
  because it returns a nonlocal address, while such
  an address is available.

6
Scalability

• Where is the bottleneck here?
• Root has to store everything.
• How to address?
• Federate/distribute the root (multiple roots).
• Each root is responsible for a subset.
• Cluster solution?
• Also distribute geographically.

7
Scalability Issues

• The scalability issues related to uniformly
  placing subnodes of a partitioned root node
  across the network covered by a location service.

8
Garbage Collection

• How do you handle a server object that is unused?
• Can it be deleted by the server?
• More context.

9
Unreferenced Objects

• An example of a graph representing objects
  containing references to each other.

10
Example

• class Class1 Class2 cls2 Class2 global
  new Class2foo() Class1 obj new
  Class1 obj-gtcls2 new Class2 global
  new Class2

11
Reference Counting

• How to avoid the double-counting?

12
Passing a Reference

• Copying a reference to another process and
  incrementing the counter too late
• A solution.

13
Weighted Reference Counting

• Can we avoid sending increment messages?

2
1
1
2
X
Increment
Decrement
14
Weighted References

• Think of each reference as a token. If you give
  each reference multiple tokens, then it can hand
  those out without contacting the skeleton.

1
2
1
Step 2 Copy of reference is made. Weight is
divided by two.
2
2
Decrement 1
X
2
Step 1 Reference created with weight 2.
1
Step 3 A reference is deleted. A decrement by 1
message is sent.
15
Weighted References

• Works correctly in the simple case.

2
2
Step 1 Reference created with weight 2.
Decrement 2
2
X
Step 2 A reference is deleted. A decrement by 2
message is sent.
16
Total and Partial Weights

• To work in real situation, the skeleton keeps
  track of the initial total weight that is
  available.
• Each proxy/stub then keeps track of how much
  weight it is carrying (the partial weight).
• When a proxy is duplicated, the partial weight is
  halved.
• When a proxy is deleted, a decrement message is
  sent.

17
Weighted Reference Counting

• The initial assignment of weights in weighted
  reference counting
• Weight assignment when creating a new reference.

18
Passing a Weighted Ref Count

• Weight assignment when copying a reference.

19
Indirection

• Creating an indirection when the partial weight
  of a reference has reached 1.

20
Generation Reference Counting

• Simple reference counting requires message for
  incrementing and a message for decrementing.
• Can we somehow combine those into one message?
  Maybe delay the increment somehow?
• Generation reference counting gets rid of one of
  the messages (the increment message).
• Basic idea is to try to defer the increment until
  we actually decrement.

21
Delayed Incrementing
1
C0
1 A proxy and a skeleton.
X
Increment 2, Decrement 1
1
C2
C0
1
C0
C0
C0
3 First proxy is deleted. It sends a message
saying it created two other proxies, so increment
ref count by two before decrementing by one.
2 Proxy created two more. Ref count at skeleton
is not updated, but first proxy keeps track of
the fact that it created two other proxies (C2).
22
A Problem
1
C0
C2
1 A proxy and a skeleton.
1
C0
C2
Decrement 1
1
X
C0
C0
3 Third proxy is deleted. It has not created any
proxies, so it just sends a message to decrement
by one. This causes the object to be improperly
deleted.
2 Proxy created two more. Ref count at skeleton
is not updated, but first proxy keeps track of
the fact that it created two other proxies (C2).
23
Generations

• Proxies have generations, as in humans.

G0C2
Generation 0
G1C2
G1C1
Generation 1
G2C0
G2C0
G2C0
Generation 2
24
Generational Ref Counting

• Creating and copying a remote reference in
  generation reference counting.

25
Deleting a Proxy

• Skeleton maintains a table Gi, which denotes
  the references for generation i.
• When a proxy is deleted, a message is sent with
  the generation number k and the number of copies
  c.
• Skeleton decrements Gk and increments Gk1 by
  c.
• Only when table is all 0 is the skeleton deleted.

26
Deleting a Proxy
G01G1-1
G0C0
G0C2
G01
1 A proxy and a skeleton.
G1C0
G0C2
Decrement G1 by 1
G01
X
G1C0
G1C0
3 Third proxy is deleted. It has not created any
proxies, so it just sends a message to decrement
by one. Generation number is different from first
one.
2 Proxy created two more. Ref count at skeleton
is not updated, but first proxy keeps track of
the fact that it created two other proxies (C2).