Re: [Vrs-development] CMM Messages

[Bill Lance]

--- Chris Smith <address@hidden> wrote:
> You're keeping it quite high-level, which is good.
> 

Trying to move just far enough down each step to find
differentiations.

Looking closer into the requirements of each level:

> Server Layer Messages
>   These will just be GWService calls between
> services
> within an LDS.
>

This level is essentially identical to the original
net packet request.  If it was a http request, it
would be forwarded unchanged, etc.  With at least one
exception.

As I'm thinking now, the original net request
recieving
LDS will amost always pass a service request on to
another type I or II LDS.  This simple step at this
the begining will insure that request fulfillment
activities get spread around the cluster.  However, a
decision has top be made here about where to send the
service task.  That decision is made by an enquiry
into the Cluster Image data about the status of
candidate LDS's.  (It might be that the decision is to
process the resquest it'self.  That's the 'almost' in
the forwarding strategy.)

As far as forwarding the originating netservice
request message onward, one additional bit of data is
needed.  That is a flag so that the delegated LDS
actually processes the request and not try to forward
it on again.


> 
> Cluster Layer Messages
>   These will be GWService calls from a GWServer
> component
> on one LDS to GWService on LDS remote LDSs.
> 
> 


These messages are between Cluster Image Objects. 
They need to be short and fast.  We have talked about
binary data packets.  Here's one of them.  They are
initiated by any LDS Cluster Image Object when a
change is made in any of it's data tables.

We have talked about at least two ways of propagation.
 The first was a complete broadcast, including data,
to all I and II LDS's.  The second approach is to
broadcast a CL change notice to ALL LDS's, the
outlying LDS's then request the data of the sending
LDS.  But the sending LDS only responds to type I and
II nodes.

We may also want to look at beefing up the mirroring
activity by a periodic verification of the state of
the CI tables.  

> Mirror Block Layer Messages
>   Again these are just GWService calls from a
> GWServer
> component on one LDS to the relevent GWService on a
> remote LDS.
>

These should be relitavly simple.  They are
essentially a fixed length block of binary data, a
action flag, and a mirror block address, directed at
one, and only one LDS node.  The data, of course, is
the contents of that mirror block.  The action flag is
either write, request, or return.   All types, I, II,
and III respond to these
 
> 
> Any more?

It levels the Server layer yet.  As sorted out to this
point, these are all internal to a single LDS.  This
is obviously determined to a large extend by the
environment used to implement the thing.  We have
talked about prototyping in PERL.  Given both the
modularity of our design, and current practices, I am
assuming that we will use OO Perl methods.  So this
brings us to the general idea of 'object method calls'
as a means of intermodular communication.  Presumable,
this approach also facilitates converting the modules
down to C.  But that still leaves the connecting
framwork unclear.  C Modules glued together with a
running perl program, presumably within the perl
interpreter is one thing.  But eventually, even the
glue will have to be in C as well.  Is there any
problem making this final transition in terms of
messaging?  Again, I'm not familar with C in much
detail. 


> 
> 
> BTW, I've solved the issue of annonymous GWDomains.
> Basically I won't introduce annonynimity into
> Goldwater,
> but provide an API where GWDomain entries in
> Goldwaters
> namespace may be removed AND added.
> So, the application you build over Goldwater adds
> and
> removes GWDomain details to Goldwaters runtime
> config.
> Goldwater needs to be configured with an upper limit
> of GWDomains it can know about at once, can be
> configured
> to know about a set number of 'fixed' GWDomain
> machines
> and the empty GWDomain slots can be filled in by the
> application as it sees fit.
> 

Does this upper limit have to be determined at compile
time or later in configuration?


> So an LDS would contact another LDS (I was thinking
> via
> the webService access port because that's the public
> bit)
> and 'subscribe' to the VRS.  If accepted, it's
> GWDomain
> details would be added to Goldwaters runtime config.

It sounds like there are certainly going to be
overlaps in the data GW needs and the Cluster Image. 
Can we move those GW tables into the CI?



> The complicated bits are:
>   1. Sending the new GWDomain details to all other
>      LDSs in the cluster.  How quickly does this
> have
>      to be achieved?

I'm not sure how quickly this will have to be.  I
think we found a way to relax these requirements with
the Pointer Table in the Repository.  Perhaps we can
find similar techniques in the CI.


>      This again comes down to having a Subscribe and
>      Publish protocol available.  More work for
> me....
>   2. Facilitating the initial connection from an
>      unknown LDS.  I'd like it to be GWService call
>      really, but that could be potentially
> dangerous.
> 
> 
>

__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com