[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Vrs-development] Mobile Agents
From: |
Bill Lance |
Subject: |
Re: [Vrs-development] Mobile Agents |
Date: |
Wed, 24 Apr 2002 05:46:14 -0700 (PDT) |
--- 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/