[Top][All Lists]

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

Re: [Vrs-development] (no subject)

From: morphius
Subject: Re: [Vrs-development] (no subject)
Date: Thu, 02 May 2002 13:20:22 -0700 (PDT)

> On Thursday 02 May 2002 07:53, address@hidden wrote:
> > --- Eric Altendorf <address@hidden> wrote:
> > > On Thursday 25 April 2002 17:07,
> > >
> > > Why would this force the entire cluster image to be
> > > sent across?  Couldn't a
> > > message, "Node X has joined the cluster" be
> > > sufficient?  Sorry, these are
> > > probably dumb questions; I'm just kind of lost here.
> >
> > This right, only the new data is transmitted to other
> > existing LDS's.  The whole Cluster Image is sent only
> > once when a new LDS joins a Cluster.
> It's the mechanism behind this that gets tricky, as you
> have to work real hard to stop cyclic messages being sent
> around.
> > The cluster image will be sent to the new LDS only once but wht about the
> > updates to other LDS connected to the VRS.
> Each LDS would periodically poll the 'cluster' to see the
> state of it.  This is done by Goldwater domains anyway,
> and you can use the API to see if a node is available
> or not.  At least that's the idea.

This idea of polling reminds me of the IBM Token Ring setup. Maybe, we could use
something very similar. When a LDS joins a VRS cluster, the cluster admin
generates a token for modifying the cluster image. A broadcast message is sent
across the VRS network indicating that a LDS has gained access to the cluster
image and will be modifying it. This ensures that the cluster image does not get
modified by more than one LDS (LDS A). The cluster admin passes the token along
with the cluster image data to the LDS A. The image is modified by the LDS A and
is retained by it. The LDS A releases then this token and sends a broadcast
message which contains the information that was added to the cluster image. The
other LDS already in the cluster just picks the token and modifies its cluster
image and then releases the token. Each time the message is slightly modified to
indicate which LDS has modified its image. When the cluster admin gets the token
, it modifies its image and verifies if all the LDS have modified their own copy
of the image. If yes, then the admin retires the token else it broadcasts the
message across again till the remaining LDS modify their image data.

How is this for starters.

> This is why I thought the data-bound Mobile Agent idea
> was a good one, in that as the message is passed from
> node to node and the tree is built up, a node can
> detect that it is already in the tree and act
> accordingly.  Also, when the message is on the way
> back to the originator, any nodes on that route may
> take the information contained in the tree and update
> their tables, thus removing the need for them to
> send out a refresh 'gather' message themselves.

Maybe the mobile data agent could do the above job


reply via email to

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