[prev in list] [next in list] [prev in thread] [next in thread] 

List:       intermezzo-devel
Subject:    Good things going into imezzo (see in the cvs logs :-))
From:       ""Peter J. Braam" <Peter J. Braam" <braam () cs ! cmu ! edu>
Date:       2000-03-05 3:54:23
[Download RAW message or body]


Hi,

Yesterday I had a brainstorming session about hierarchical caching,
aka proxy servers.

At the top of the tree there is a single master:

M
P1           P2 .....
C11 C12..    C21 C22 ...

etc.

It appears to be slightly tricky to support moving client from one
proxy to another.  Let's assume the client-proxy relationship is
statically organized for now.

Also we merely thought through the replicating case.  The one with
fetch on demand might be slightly trickier.

1. C1 clients declare the server to be P1

M has P1 P2 as replicators and has no knowledge of C's.

For P's we have two possible solutions:
P1 declares M to be a replicator, and itself to be the server, in
addition to the other clients it has as replicators.  It would know
that M is the "sync master" to be contacted upon first sync.

- or -

P1 declares M to be the server and P1 is "proxy aware": despite that P1
is not a server is know that it should still forward updates it
receives to M.


2. When a lock/permit needs to migrate from C11 to C21 the following
chain of events would work:

C21 asks P2.
P2 thinks that M has the permit - and asks M
M last gave the permit to P1 and gets it back.

Before making a decision on what might work ,we would also want to
think about possible conflicts.  A conflict among replicas on the P's
is going to be unpleasant, at M it might be worse.

- Peter -

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic