--- Begin Message ---
|
Subject: |
Re: [Vrs-development] More info |
|
Date: |
Wed, 13 Mar 2002 16:28:56 -0800 (PST) |
> 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.
I was treating the cluster admin as the server and the
LDS nodes as clients when they sign up to join the
cluster.
We will have to support server and client
authentication for web services. We could treat that
as one of the plugin for the Service framework
> 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.
Good enough. We also might have consider export
conditions of various countries which prevent certain
the spread of 128 bit encryption. This means that
different algorithms will have to be used for a
network as global as VRS.
> > > 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.
It all depends on how determined the hacker is.
> > > 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.
I might have still not understood the concept
properly. Let me get my thoughts sorted.
The LDS connected to the VRS is spread around the
world. Each VRS cluster is made up of only few LDS
nodes. How many? and who determines the limit?
> > 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.
Looks good
> > > > 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.
One more clarification, when an LDS joins the cluster,
who provides the cluster image it requires. Since none
of the LDS nodes have any information regarding the
new LDS, the new node has to modify the existing CID
and broadcast it. Is this thinking correct.
> > 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.
Is it possible to advance a single Level II node to a
Level I node? This will take care of issues such as
addition of new nodes.
Each time a LDS joins the cluster, it could notify the
cluster that it has a static IP (an important
consideration, Is there any other consideration). This
change can be noted in the cluster image. All the
nodes that have a static IP can queued up to act as
cluster admin if the main cluster admin goes down.
Then using a poll, the LDS which are capable of acting
as cluster admin, will appoint a new LDS. This change
can be broadcast to all the LDS in the cluster.
There will be a slight problem if the cluster admin
goes down when certain web service clients are
connected.
> > 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/
--- End Message ---