Re: [Vrs-development] More info

[Bill Lance]

--- Open Source <address@hidden> wrote:
> > Your right, there is always that possibility.  The
> > question is what can we do to reduce it to
> > negligable
> > proportion.
> 
> Is it possible to use client/server authentication
> for
> this purpose?
>

Getting our 'client', 'server' and 'node' terms sorted
out in this thing can be a bit confusing.  First off,
there is the client-server relationship between a
running VRS and netservice request clients.  This is
external to the VRS, itself, and from the point fo
view of the client, it is no different than contacting
any server on the Internet.  Within the VRS nodes,
there is no real client-server relationship except for
the transient, and often bidirectional,
request-response relationships of the typical p2p
network.

Looking at thes seperately, external authintication
services are definately possible.  In fact, the whole
idea of the VRS evolved from search for a way of
countering the Passport authintication system.  It is
anticipated that personal authintication services,
under the control of the 'person', will be a major use
and reason to exist for the VRS.

Internally, we are definately looking to authinticate
nodes on login.  Probably, we will use SSL, for
several reasons.  One, it's simple to implement. And
two, SSL traffic on the net is difficult to isolate
because of it's common use in commercial traffic.

  
> > 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.
> 
Great.  I don't know much about this particular area.



> > 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.
> > 
> 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
> image 
> 1) The cluster for which it is the admin
> 2) The cluster where it a member
> 

You misunderstand, a VRS Cluster is an isolated,
individual entity.  It has no relationship what so
ever with other VRS's.

The GLOBUS system might be more like what your
thinking about.


> It also has to broadcast the services that this
> cluster can provide. 
> 

This is an issue that the VRS itself does not have to
contend with directly.  There may very well be a UDDI
service provided in the Service Manger Framework as a
plugin.  But other things are also relevant.  One of
the big ones is, I think, structuring the directory
service so a URI can drill into it.  


> > arises, one or both DLS's will poll the other
> LDS's
> > in
> > the Cluster for a correct value, majority ruling.
> > 
> >  
> Wont this increase the network bandwidth.

Yup, it sure will.  But we don,t know by how much or
if it will be unacceptable.  This kind oif question is
one of the reasons we want to start with a prototype
in PERL first to test this kind of resource balancing.

 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
> each other.
> 

True.  One thing, we are looking at a binary packet
encoding for this level of communication, NOT an XML
type thing.


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

To further clarify this question, after a new node
initially loads the complete CI after loging in, only
transactions are sent and recieved. THe whole CI adcts
like a DB, changing only in responce to transactions.


> 
> A poll can be made of which of the level II LDS
> nodes
> can be made admin till the level 1 node returns
> online.
> 
>   This means that no new node can be added to the
> cluster as well as any existing node that has gone
> down.
> 

humm  ... you have a point there.  


> 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.
> 
> If the level 1 node returns online, how will it
> notify
> the cluster?
> 

This all brings to fore some confusion in my mind
about the differences between I and II nodes.   The
reason and boundries on III's is clear.  They are
simply not trusted, period.  Seperating I and II makes
sense, but not as compeling as seperating out III's.

We may need to think more about this.  Once again, how
nice a test model will be.



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