[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Vrs-development] More info
Re: [Vrs-development] More info
Tue, 12 Mar 2002 18:36:20 -0800 (PST)
> > 1) How trustworthy is the cluster administrator?
> > 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
> > 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
Is it possible to use client/server authentication for
> So far, the design calls for that to be handled by
> 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
> There does exists the possibility of IP address
> spoofing, however.
Once the client and the server authenticate, i don't
think there will be any IP spoofing.
> > 2) The cluster image object size can vary
> > 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
> Clusters, not one hugh one.
This adds to the complexity of VRS. Each VRS cluster
will have a cluster admin which in turn will be part
of another VRS cluster. This means that the cluster
admin will have to maintain more than one cluster
1) The cluster for which it is the admin
2) The cluster where it a member
It also has to broadcast the services that this
cluster can provide.
> As we see at now, a VRS Cluster requires the
> 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.
> 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
> arises, one or both DLS's will poll the other LDS's
> the Cluster for a correct value, majority ruling.
Wont this increase the network bandwidth. Is also
introduces a whole lot of network security issues.
Even though the cluster admin has authenticated the
LDS, the LDS still have to determine if they trust
> > 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
> by a round-robin deligation of the conroling node.
> However, this issure remains open in the rest of the
> > 5) Suppose the cluster administrator goes down,
> > 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 poll can be made of which of the level II LDS nodes
can be made admin till the level 1 node returns
This means that no new node can be added to the
cluster as well as any existing node that has gone
A possible approach is to be sure all the necessary
> is preserved in Level II nodes, even if they are
> unable to act on it, till a Level I returns online.
If the level 1 node returns online, how will it notify
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!