[Vrs-development] Summary of 7-14-2002 Meeting

[Ian Fung]

In the meeting, we talked about the CM and the RM.

The first issue that was brought up was discovery of nodes in the CM.
There seems to be two ways to solve this problem. One is to maintain a
list somehow of all LDS nodes in the VRS. Whenever nodes needs to be
queried for file sectors or services, each LDS will know of every other
LDS in the VRS. To do this, each LDS would have to be updated whenever a
node joined or left the VRS. Also, nodes will have to be notified if an
LDS had a new service installed. Unless something clever it done, this
solution will not scale simply because as the number of nodes increase,
the amount of information kept by each node will also increase. On the
other hand, this solution will be much easier to implement, than say, a
dynamic solution.

A more ambitious route to take would be to implement a fully dynamic
solution which would take advantage of the multihop environment of the
p2p cluster. If discovery of LDS's and their services were done
dynamically, it leaves much room for "cleverness" such as rerouting
traffic, load-balancing, remote caching, etcetc. Since everything is
done on-demand, performance will be greatly increased due to the
reduction of meta-data in the network. Implementing a dynamic solution
is very ambitious and may be limited due to what is already provided for
in the Goldwater Middleware. I do not know much about the GW stuff so I
am just speculating. One point I would like to reiterate that was
mentioned at the meeting is that only discovery would be done
dynamically and in a multihop fashion, but when actual data needed to be
transmitted, it could be done directly.

Chris is actually in charge of the CM because of his ties to Goldwater
so I guess Chris will just end up designing the CM.

The other important topic we talked about was the RM. The RM houses the
distributed file system (DFS) and manages all access to it. The access
to the DFS via the RM was not talked about that much. The major
undertaking in this area is actually creating the DFS. There are several
requirements for the DFS. The major ones are consistency and
sychronization. It was pretty clear that the nodes that need to perform
those tasks (nodes with the same file sector) needs to be structured in
some way. It seems impossible to coordinate nodes if they are not
structured. Someone needs to sit down and plan out how those
nodes will coordinate themselves to stay consistent and be sychronized
(ie maybe changes wont be committed until everyone votes on them). Other
areas that needs to be dealt with are duplication, partitioning of data,
and load-balancing. If a structure was setup for consistency and
duplication, then it would seem likely that it could be used to write
algorithms for the other things. The heart of the DFS is a way to
coordinate nodes, ie transaction management.

A third area that didn't get much attention at the meeting was security
and trust. The main concern that was brought up was how the trust model
would be handled. For example, it is apparent that a LDS to LDS
authentication system would be required. Will that same identity be used
for authenticating access to the DFS? An idea that I had put forth was
that each RM should have a shared key with the DFS and should
communicate via that. The RM would then be in charge of access control
and handle LDS authentication (its own and also others). That is the
kind of thing I mean when I talk about a trust model. Basically who has
its own keypairs, what are considered entities, etc.

Freport talked to me about possible integration of address@hidden with VRS.
To be honest, I don't know that much about address@hidden yet, so I can't
say for sure. And also, we don't really know what we're doing for
security. If somone wants to take a stab at it, great.

So that's about it. I was going to post links on information that would
be useful, but it's late and I dont want to do it right now =P. So I'll
post links to stuff tomorrow. I also didn't read what I wrong over, so I
apologize if some of it is incoherent. Please correct me if I messed up.
I don't know who is in charge, but I think we should start making some
definite plans.

That's all for now. Thanks for listening. =)

Ian