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

[Chris Smith]

On Monday 25 March 2002 18:52, Tim Terlegård wrote:

> If there's no control it will be easy make a DoS attack to the VRS by
> adding numerous of services.
>
> To become a member of a VRS one should authenticate and then it's decided
> whether the node can join or not? This means there will be a central server
> for adding services, right?

Possibly not.
One objective is that the whole thing is de-centralised.
There has to be some responsible party willing to deligate subscriptions etc.
Once your LDS has joing the VRS it starts sharing the service data that
already exists in the VRS, and also adds its own.
It's this initail connection authority that's the trick I feel.

But it all gets really complicated because the data that constitutes the
services within the VRS is shared by all LDS's in the VRS.  This data is
supposed to be encrypted and no one LDS is supposed to have the entire
data set that makes up a single service.

Now I have trouble with this beacause:
a) Services deployed within the VRS are supposed to be able to execute
   on any given LDS.
   - This infers that every LDS has the decryption key for the data in
     the data pool.
b) Any LDS of the VRS is able to add new services to the VRS or remove
   any which it owns.
   - This inferrs that every LDS has the encryption key for the data in
     the data pool.

Which negates the point of encryption, unless:

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.

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.

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.

> Let's get back to Service Discovery. How do you know whom to ask what
> servces are available? 

Yep, you're seeing the same problem.

> Probably my university would put the IP of their VRS
> node on the homepage and one could ask that one. 

See we do need an external server, or network of servers like DNS.

> So really, why an arbitrary node be capable of telling what services 
> are provided in the
> domain (VRS cluster)? If I want to join a VRS cluster I (probably) have no
> idea about the IPs of the nodes. I must know the IP of a node so I can ask.
> Let's say every node can tell about the domain's services. If someone tells
> me the IP of a node, then I can ask about the cluster's services. But if
> that machine dies I have no idea who to ask. I don't really see where the
> distribution power of p2p can help in this Service Discovery issue.
>
> Right now a central Service Discovery for each domain (and subdomain) where
> one adds services makes most sense to me. What do you think?

Get Out Of My Head !!! :)

We need a DNS like self supporting, self updating query database thingy.
I don't know how this is 'proposed' in the (whisper...) .Net world.


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

I need to think about this.  I'll get back to you with more.
Oh - careful talking about VRS Domains..... because the VRS is going to be
built using Goldwater Domains, each one a single LDS.
What about VRSlets??  For instance, a VRS may consist of a collection of 
LDS's or a collection of LDS's and/or VRSlets.


Bill, What's your take on all this????


Chris


-- 
Chris Smith
  Technical Architect - netFluid Technology Limited.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk