Re: [Vrs-development] CMM Messages

[Bill Lance]

Hi Chris,

Sorry for not writing much this last week.  It's bee a
bit hectic.



--- Chris Smith <address@hidden> wrote:
> On Friday 01 March 2002 19:24, Bill Lance:
> 
> > This brings a question to mind.  How does GW get
> > configured in the first place?  It faces the same
> > configuration issues that the VRS does.  It starts
> > with only one, other nodes are added, and the
> original
> > one may drop off line.  A new instance of GW must
> > start each time a LDS comes online and sync with
> the
> > other GW components to other LDS's.  If GW
> > configuration data is not carried in the CI, you
> will
> > still have to accomplish similar mirroring tasks.
> 
> In this application, GW would be configured with n
> GWDomain
> slots, but none filled.
> Which GWDomains (ie remote LDSs) the local LDS knows
> about
> is configured dynamically by the LDS itself because
> the
> local LDS runs through the GWDomain API.  The
> maximum
> number of LDSs our local LDS can know about at any
> one
> time is n.

How much of an over head is each n?  Can this be set,
or reset at run time instead of being compiled in?


> 
> i.e. the LDS gets a 'Hey I want to Subscribe'
> message from 
> another LDS, it checks it out and then tells
> Goldwater about
> it.  Goldwater then deals with the whole up/down and
> 
> routing thing.
> 
> Hmm (just had a look at the your documentation
> again....)
> I think the cluster management is performed by
> Goldwater.
> But all it knows about is how to manage the
> availability of
> cluster machines and the routing of messages between
> them.
> Any additional business-logic details about these
> machines
> is left up to the application - the LDS in this
> case.
> 
> The subscription of an LDSs to a cluster is an
> function of 
> LDSs and not Goldwater.  If the LDS tells Goldwater
> about
> the remote machine, Goldwater can get on with
> managing its
> availability and routing messages to it.  Goldwater
> is
> there to support the application built apon it.
> 
> Yes both Goldwater and the LDS application will have
> tables containing slightly overlapping data sets.
> Its like having a normalised database where a single
> chunky table is split into two tables, both keyed on
> the same value(s).
> 

What information does GW need to keep?  Is that keyed
to an IP number?



> Whatever is in Goldwaters table the LDS can 'see'
> through the API.  Whatever is in the LDS table
> Goldwater CANNOT see 'cos that is application
> sepecific.
> 
> We're effectively ripping out of the data stored in
> the LDS CI whatever Goldwater needs to manage the CI
> routing etc and giving it to Goldwater.  The LDS
> application can still get at it and uses it to
> augment the data GW doesn't care about.
> 
> I've probably repeated myself a little bit in that.
> Sorry if I did.  Do you see what I'm getting at? 

Yup, or getting there  :)

> Take
> the functionality that the CI needs to perform and
> axe off those bits which Goldwater does for you.
> Add in a bit of functionality to smooth over the
> seperation and you'll end up with two cooperating
> function sets that together form the CI.
> 

WHet in detail is the GW set?  (Same question as
above, I supose.)

My next task was to start detailing the CI data
structure, so this is most timely.



> > In the LDS block diagram in the Docs, would it
> make
> > sense to place the GW component bwwteen the port
> > manager and the others?  Like this?
> >
> > _______________________
> > |      Port Mang      |
> > -----------------------
> > |          GW         |
> > -----------------------
> > | RM    |  CM    | SM |
> > -----------------------
> 
> More like this I think:
> 
> ________________________
> |        Port Mang      |
> +-----------------------+
> |          GW           |
> | ,----. ,----. ,----.  |
> | | RM | | CM | | SM |  |
> | '----' '----' '----'  |
> |                       |
> '-----------------------'
> 
> All components of the LDS interact with each other
> indirectly via GW don't they?

see below.

> 
> Does this diagram illustrate that?  TBH some arrows
> would be nice in that to show that RM CM and SM
> communicate with each other and the PortManager - 
> so they don't look so isolated.
> 


I have that in the Server Layer Messages figure.  (If
you looking at a cvs copy instead of the homepage or
current cvs, it may be out of date.)

Which is a question I was leading to, as you asked
above.  Does it make sense to use GW for communictions
within this Server Layer?  All the modules, including
GW, would be equally exposed to all other with API's
within the LDS instance namespace.  Does GW add value
in this case?



__________________________________________________
Do You Yahoo!?
Yahoo! Sports - sign up for Fantasy Baseball
http://sports.yahoo.com