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

[morphius]

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

All the LDS will have to contact the cluster admin to gain access to the VRS
cluster as the cluster admin is the entry point into the cluster. All the
cluster admin has to do handle them individually. 


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

 The cluster admin has all the information on how many LDS's are 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


Just a couple of questions 

1) who will be originator of the MA
I think i just answered this question. 
  The cluster admin will update the MA and send it along to the next LDS which
in turn will send it to the next until the MA routes back to the cluster image.

Make sense.

2) Suppose a LDS goes down when there is a MA in the network and comes back up
after the MA has passed it (just a hypothetical situation :-) ). Now, there are
two MA's running around in the network. 

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

Yeah, i can understand :-)

- Morphius