Re: [Vrs-development] The Cluster Image

[Chris Smith]

On Thursday 21 February 2002 17:09, you wrote:
> Chris,
>
> Do you still see problems with Implementing the
> DataImage and Cluster Management Messages idea in GW
> or do we have to rework either in some manner?

I don't think there'll be problems.

Anonymous GWDomains are a new concept for Goldwater
(usually you'd configure Goldwater supporting your
application to know about a finite set of GWDomains
with which your application may link.  If we introduce
anonymous GWDomains, then at configuration time you 
have no idea how many GWDomains there may be.
I'm thinking about performance, as the GWDomain and
GWService tables are memory based and I need to know
how much memory to allocate up front.

Bill, if you think that it is acceptable to set a MAX
limit at configuration time, then that will help.
Question: What happens if different LDSs are configured
with different MAX GWDomain settings??  Interesting....

Back to your question:
CMMs will reduce to GWService calls that the designated
LDS will receive.  The code that issues the GWService
call will need to choose the appropriate namespace for
the call destination so that the correct LDS gets it.
(Now I've got an idea for message dependant routing, but
 that's tricky and it might be easier to set the dst.
 namespace up front, before the call).

Also I'm going to bring forward my plan for GWEvent
messages (Broadcast events that are received by
any Goldwater Application Component that subscribes
to a particular event).
This bit will take some work as there are performance
issues (with very large applications subscribing to
a large set of events - but I don't think we'll have
that situation here - I'd like to get it done though
as they're essential for sending notifications!).

The communication between GWDomains may be link level
encrypted and compressed (though I'm thinking that we
may want to disable compression when sending a block
of repository data and do the compression ourselves -
this'll keep the repository size down. Note that SSL
support in Phoenix has not been done yet (started
but not finished) - and it may be added in at a later
date without influencing the LDS implementation.

There is a small security risk with Goldwater in that
when transferring messages around the 'architecture'
and delivering them to the destination process, if they
are larger than a certain threshold (configurable)
they get spooled to disk and a reference is passed
around instead.  Anyone with root access could examine
these (very short lived) blocks of disc data.  We've
got a root access issue anyway, so I'm not worrying
about this at the mo.  It might be possible to move
the decryption of the messages to the final destination,
so you'd never get plaintext dropped to disc.
However, if you've got root access you can get the
key to decrypt the data.
[Ah, we've got two levels of encryption:
 1. The repository blocks themselves are encrypted and
 2. The link between GWDomains (LDSs) is encrypted.  

So I imagine that the data that could get temporarily 
spooled to disc would still be encrypted at Level 1.
Again, if you've got root you could have the key......
]

Dull day in work today so I'm rebuilding some of the
administrative tools of Goldwater - this is nearly
complete (hard to find the time at the moment).

Once done it will be releasable.  Hurrah.

There won't be GWDomain support at this point.  That'll
come next but will be re-designed to (at the very least)
support the LDS to LDS communication behavior we're
after.
We'll still have to write the LDS specific code though,
which is basically a GWService which SENDS a CMM and a
GWService that RECEIVES CMM.  The connection between the
two is the GWDomain implementation.

Anonymous 'subscribe/unsubscribe' support will also be
part of the GWDomain implementation, with some funnies
such as automatically dropping a subscription if that
anonymous GWDomain has been unavailable for a period.

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