[Top][All Lists]
[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
- [Vrs-development] Mobile Agents,
Chris Smith <=