vrs-development
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Vrs-development] (no subject)


From: Chris Smith
Subject: Re: [Vrs-development] (no subject)
Date: Fri, 3 May 2002 15:32:29 +0100

On Thursday 02 May 2002 22:00, Bill Lance wrote:

> My working thought about how this would work is not
> based on polling activity but on broadcast messaging.

Yes it would be done through some message or other.
However, Goldwater internally periodically polls other
Goldwater Domains to make sure they are still alive.
It does this instead of waiting until it tries to
send a Domain a message only to find it's not there.
If it already knows a Domain is not currently 'on line'
it can route the message somewhere else, queue it for
delivery when the domain becomes available again (if
the message channel is marked as reliable), or just
fail immediately.

If Goldwater didn't poll periodically, then it'd have
to do everything at the time of delivery - which may not
be the most oppotune moment.  This poll period is user
configurable, so you could set it to be a number of
hours!

> When a change takes place in the Clusater Image of any
> one LDS, that change transaction is broadcast to all
> online LDS's updating eaches Cluster Image.  The trick
> will be keeping the individual Cluster Images
> reasonably coherant and similar.

This is what I propose achiveing with the Mobile Data Agent
idea.  It's a little 'researcher' that goes out and
discovers the world.  Any node through which this agent
passes can extract info about the new node (the
originator), or any other node that may have added its
detail to the tree.

> Polling might well be necessary to verify the state of
> an LDS.  A periodic check sum was suggested once.
> That might not work if the LDS's are in various states
> of updating themselves in responce to update messages,
> however.

This GW polling merely lets goldwater know the state of
the Goldwater domain, not the state of the application
that is using Goldwater (ie the LDS).

If you want to query the state of the LDS, you'd need
to create an application specific message to transport
this status information.

And yes this Cluster Image thing is very interesting, and
is sooooo close to what Goldwater does that I'm trying to
marry the two together (seeing as I'm reworking the
Goldwater Domain implementation), but this might mean
bending Goldwater's concepts (so long as they don't
stop being generic) and bending the LDS cluster image
concepts (so long as they don't stop being functional!)

Chris

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]