Re: [Vrs-development] The Cluster Image

[Bill Lance]

--- Chris Smith <address@hidden> wrote:
> On Thursday 21 February 2002 17:09, you wrote:

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

Humm .. this brings up an important issue.  I was
waiting for a settleing of this before moving into
detailing the Cluster Manager section.  And the first
step of that is to start detailing what's in the
Cluster Image.  It sounds like many of the
configuration table in GW overlap with some of the
tables I was thinking should be in the Image.  The
list of both subscribed, and online nodes (or Domains
in GW speak, if I have it right yet  :(  ) sounds like
just such a critter.

Wnat's in GW that's going to need to be mirrored to
all nodes?

About presizing allocated memory, :(  I haven't a
clue. Of course, development models can be fixed size,
but the real thing?  I don't know.  Also, I was
thinking that Cluster Image table would necessarily be
dynamic.

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

Could you explain the basic mechanisms of a GW call? 
I think I really need to understand this at lot better
than I do.

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

Subscribing to a GW even is a configuration flag, I'd
assume.  Perhaps this is the mechanism to enforce the
level I, II, and III functionality.

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

I hadn't thought about compression.  Does this work on
encrypted data as readily and text data?

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

I came accross an interesting note about SSL lately in
connection with the recent buzz about the Peek-a-boo
p2p system.  The are planning on using SSL because
it's packets are indistinguishable from a HUGH amount
of other net traffic.  They figure it would be
impossible to filter and track them in firewalled
countries.  That sounds like an interesting and
valuable feature, especially considering our Prime
Directive (security and privacy).


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

Ya, this could indeed be an issue.


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


hehe  .. kind of a vicious circle

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


What's this require from the GW side of things?


Want to try for an IRC today?


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games
http://sports.yahoo.com