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

[Chris Smith]

On Tuesday 26 March 2002 02:50, Open Source wrote:

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

Well, yeah, okay a proven model, but it won't work with
the VRS.  The VRS is supposed to be distributing the
data/service set provided by its component LDS's.
So when a request comes in at any given LDS, the distributed
blocks that constitute the requested service are
gathered up from wherever they are in the cluster.
Most of them may exist on the LDS that is processing
the request, but not all - that's a design feature.
Now if each LDS has encrypted their portion of the
data with different keys, then managing this becomes
a real problem.

Unless the LDS that has been asked for a data block
decrypts it and then sends it to the requesting LDS
via SSL.  Performance will be crud then.

I'm writing a parallel email suggesting some design threads.

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

No we definately want somehing loosley coupled like
a DNS model.  See my next email!

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

This was the original idea.  Tim suggested that
interconnecting VRS's might be useful, and it certainly
solves the managability problem of a BIG VRS if we
can sub-divide it.
Question is how much?

See next email !

Chris

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