Re: [Vrs-development] More info

[Bill Lance]

Hi Morphius,

I'm glad that you can join us.  Before getting to your
specific questions, let me mention something that I
didn't want to take up bandwidth in the developers
list with.

The VRS project is taking a top down design approach. 
The architecture is going to be substantially
completed before we start writing serious code.  :) 
However, part of the plan is to do early prototypes in
PERL  ...  so we wouldn't have to wait too long to
start playing.



--- Open Source <address@hidden> wrote:
> Hi
>  I looked up the web site. The first line in the
> project overview is "it is not a gnu project" yet is
> under a GPL license. Could someone explain what this
> means?
>

I'm not to terrably clear about this, but being a 'GNU
project' involves a code review and approval process
of the FSF.  Most GPL'd progams are not GNU projects. 
This is a more fomal process that we intend to move
through as code is developed.  Norbert Bellow can tell
you more about this.

 
> I was just brushing through the VRS docs and i have
> some simple questions
> 
> 1) How trustworthy is the cluster administrator? We
> have been talking about authenticating the client
> but
> is there any way of authenticating the server? The
> same question goes to the LDS as well. There is
> always
> a possibility that the rouge LDS gain access to the
> cluster image data and cause harm to the cluster. 
>

Your right, there is always that possibility.  The
question is what can we do to reduce it to negligable
proportion.

So far, the design calls for that to be handled by the
state of the VRS itself when a new node logs on. 
Remember that a node has to be subscribed to a
particluar VRS Cluster, or a connection will not be
accepted.  This is NOT an open connection p2p like
gnutilla.

There does exists the possibility of IP address
spoofing, however.

 
> 2) The cluster image object size can vary depending
> on
> the nodes in the cluster. There is a very distinct
> possibility that LDS could be spread all over the
> world. The size will play a very important role on
> LDS
> which are burdened by slow network connections.
>

There may hopefully be LDS all over the world, but
they will all be talking with a small group of other
LDS's.  In other word's this would result in many VRS
Clusters, not one hugh one.

As we see at now, a VRS Cluster requires the consensus
of it's participants.  Remember that this is NOT the
same as it's users.  To net users, the VRS is just
another net address and related services.  The
participants, however, create that service in two
ways. First, they are the source of the content.  The
second way it to share the cpu and memory demand
needed to provide the serives.
 


> 3) what happens if there is conflicting cluster
> image
> data turns up?
>

This has not be documented yet, but the thought is
this.  The LDS will maintain a CRC calculation on
elements of the CI.  It will periodically tset that
value against that of other LDS's.  If a discrapancey
arises, one or both DLS's will poll the other LDS's in
the Cluster for a correct value, majority ruling.

 
> 4) what happens if more than one node changes the
> cluster data and broadcasts the image across the
> cluster?
>

We have addressed this problem in the Repository data
by a round-robin deligation of the conroling node. 
However, this issure remains open in the rest of the
CI.
 
> 5) Suppose the cluster administrator goes down, the
> entire cluster goes down. Which LDS chooses to
> become
> the next cluster administrator?
> 


Any Trust Level I node can act with full
administrative power.  This is more a configuration
issue.  If there is only one Level I node configured
in the Cluster, this is a real possibility.  A
possible approach is to be sure all the necessary data
is preserved in Level II nodes, even if they are
unable to act on it, till a Level I returns online.



__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/