vrs-development
[Top][All Lists]
Advanced

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

[Vrs-development] Mobile Agents


From: Chris Smith
Subject: [Vrs-development] Mobile Agents
Date: Wed, 24 Apr 2002 12:35:41 +0100

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)


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



reply via email to

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