Re: [Vrs-development] IBM Token Ring Thingy...

[Chris Smith]

On Thursday 02 May 2002 21:20, address@hidden wrote:

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

Yep, but you've still got the problem of two or more LDS's broadcasting the 
'claim cluster image' to the cluster.  You can't have more than one claiming 
the cluster image, so this should fail.  However, it's really difficult to 
engineer because you've got to detect that all nodes in the cluster accepted 
the SAME claim message from the same LDS.  This is hard enough, without the 
added complication that you may not know about all LDS's in the cluster.

This is why the MA approach may help.  Each LDS maintains it's own view of 
the cluster image, and is kept in sync as best as possible.  It doesn't have 
to be immediate (and I think we should design with this in mind) because we 
have to deal with the case of LDS's going offline and coming back.  Thus the 
MA idea allows all scenarios to be dealt with.  If an LDS comes back on line, 
then a lot might have changed, and the MA 'data tree' will return a wealth of 
information.

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


I think so - but it's a theoretical idea - but I can clearly see how to 
implement it and it *does* overcome some stumbling blocks I've had (and to be 
honest never solved satisfactorily) in the past.

Bouncing ideas - you know how it is ... :o)

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