Re: [Vrs-development] Mobile Agents

[Bill Lance]

--- Chris Smith <address@hidden> wrote:
> On Saturday 23 March 2002 19:13, Tim Terlegård
> wrote:
> 
> > Mobile Agents -
>
http://www.infosys.tuwien.ac.at/Research/Agents/intro.html
> 
> 
> An idea occured to me last night which (hopefully)
> solves an LDS subscription 
> issue I've had in the back of my mind.....
> 
> Each LDS needs to 'connect' to 2 or more other LDS's
> in the VRS cluster to be 
> even sure of a reliable connection.  The more the
> better etc.
> 
> How does the subscribing LDS get to know about the
> other LDS's in the cluster?
> Well the VRS member LDS that our subscribing LDS
> contacts in order to join 
> the VRS needs to have a complete list of all the
> other LDS's in the cluster.
> (What a mouthful!)
> This is bad.  Difficult to engineer and I just don't
> like it :o)
>

What do you see as the problem with each LDS
maintaining a complete list?  With an open p2p sytem
like Guntilla, I could understand this question.  But
with a closed, finit cluster like VRS, there shouldn't
be all that many node in the cluster to begin with.

 
> 
> And then the idea of a pseudo-mobile-agent came to
> me.
> 
> Basically each LDS has an internal method which on
> receipt of a special 
> message, adds it's own 'details' to it and forwards
> it to ONE of the LDS's it 
> is connected to.  If it has no (more) LDS's to
> forward to, it marks the chain 
> as complete returns the message back the LDS it got
> it from.
> If an LDS gets the message back, it sends it to
> another LDS that it is 
> connected to, until it too runs out of 'child' LDS
> and marks the chain 
> complete.  And so on - walking the network of
> connected nodes.
> 
> Basically we've got a data-bound roaming agent.  The
> agent doesn't need a 
> code-body because we can guarantee that each LDS has
> it.
> 
> The originating LDS ends up with a connected graph
> of all other LDS's in the 
> cluster, which is MUCH better than just having a
> table of IP addresses of 
> LDS's that a given LDS may connect to as we can
> 'see' the existence of a 
> remote LDS that we cannot connect to directly.
> This opens up a whole host of message routing
> options that just were not 
> possible before.
> 
> I'm considering whether this should really be a
> component of the middleware 
> or an application specific component (ie the LDS). 
> This is just a layering 
> issue and won't effect the functionality at all.
> 
> It is probably sufficient that not all LDS's are
> connected to all other 
> LDS's, as long as there are routes through.  How
> this is decided is still up 
> for grabs, but given a complte node graph we have
> the option to connect to 
> all or just our nearest nodes.
> 
> 
> I'm wondering whether the 'chain' message passing
> through an LDS on the way 
> back to the originator may be parsed by the
> intermediate LDS in order to 
> update it's own view of the world.  Need to think
> about this more as there 
> are issues with the graph being incomplete at this
> time....
> 
> 
> Any thoughts?
> 
> 
> Chris
> 
> _______________________________________________
> Vrs-development mailing list
> address@hidden
>
http://mail.freesoftware.fsf.org/mailman/listinfo/vrs-development


__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/