Re: [Vrs-development] VRS and SEE/DEE goals

[Open Source]

> The encryption/decryption keys are handed out by the
> VRS whenever an LDS
> joins the VRS cluster.  These keys are held in
> memory and never written
> to disc (the memory page which holds the keys is
> told NOT to swap) - we
> also need to protect against core dumping.
> 
> It's all supposed to stop arbitary users from being
> able to peer into the
> data pool.

We could use the concept of sessions. Everytime an LDS
joins the cluster, it gets a session key along with a
randomly generated keys(negiotiated). To makes things
interesting, the LDS has to renew the session before
the session times out. During the session renewal, a
whole new set of keys are negotiated.
 
How abt this approach?


> But it's still a bit dodgy.
> I wonder what sort of attacks we open to in this
> scheme?


> > Should there be a central Service Discovery Server
> or can I ask any VRS
> > node what services are available?
> 
> I want to fall in line with whatever scheme everyone
> else is using for
> web service discovery.  The fact that we're
> designing a cluster architecture
> here is transparent to client that really just want
> to call a service.

Isn't there any open standard for identifying web
services on the net? Every major company is talking
abt web services so they must have thought abt how to
identify web services on the net.

> No one seems to know what UDDI type thing should be
> used.
> When I get far enough to cobble together a dumb LDS
> Goldwater Application,
> we could build an 'internal' webservice that just
> returns an XML directory
> listing of the services currently deployed in the
> VRS.
> Being modular, this can be swapped out later when we
> have something more
> suitable.
> 
> You should be able to ask and LDS what services are
> available.
> OR any of the 'public' LDS's.  However, How do you
> know the IP addresses fo 
> the public LDS's ????
> I still see we need some sort of server that is
> 'external' to the LDS/VRS 
> that can serve the whole dotGNU community, whether
> or not they are using 
> LDS/VRS technology or not.

Doesn't this change the entire oulook of VRS? If this
"external" is to be hosted on some web site, it has to
be a very powerful system. 
Why can't we use something like gnutella does?
We have a special set of VRS cluster which act like
DNS server.Each VRS cluster registers with this DNS
cluster. There could be a public IP address on the
dotgnu web site for this purpose. This IP could be the
cluster admin or an LDS for the DNS cluster. every LDS
attempting to join the VRS requests the DNS cluster to
provide an IP closer to its domain. When the LDS joins
the cluster, the cluster admin could authenticate and
provide a list of web services supported? This also
approach could be extended to clients wishing to use
these web services.

> I'm definately with you on the Sub-Domain idea, Tim.
> And it's really simple to arrange I think, as a VRS
> looks like a single LDS 
> really..... so the macro-domain would just see
> another LDS - or so it thinks.
> 
> In fact I was loosely thinking about this over the
> weekend because if we were
> to deploy LARGE VRS clusters as a cluster of
> sub-VRS's, then that becomes
> very much more managable.... but then I started
> getting into trouble with the 
> internal message routing (LDS/VRS control messages -
> Goldwater Service calls 
> to be exact) and how to get them across VRS-Sub
> Domain boundaries....

It seems that we are going back to the  client/server
model. Why don't we think abt individual VRS not
related to one another. Only link existing is within
the DNS cluster. Any service discovery is done thru
this cluster.


-Morphius

__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/