[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Vrs-development] Mobile Agents
From: |
Eric Altendorf |
Subject: |
Re: [Vrs-development] Mobile Agents |
Date: |
Wed, 24 Apr 2002 11:32:51 -0700 |
I guess I don't fully understand the point....
1: Assuming that all LDS nodes are on the internet, we already have a
flexible, redundant, extremely reliable routing mechanism, and all nodes
should be capable of making direct connections to all other nodes.
2: Why is it easier to build a node graph than to keep a table of nodes? It
seems to me that in searching the node graph one is building a table of nodes
anyway. Being able to build a graph means you can build a table...they're
equivalent...
3: Now, that being said, there may be a point in having a node graph anyhow,
if you store bandwidth and ping time information. For example, if node X has
to grab some data which is stored on both node Y and node Z, but the node
graph knows that the average bandwidth between X-Y is much higher than X-Z,
it would make sense to talk to node Y first.
Any feedback?
Eric
On Wednesday 24 April 2002 08:59, you wrote:
> On Wednesday 24 April 2002 13:46, Bill Lance wrote:
> > 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.
>
> Well there has to be some mechanism where info about the
> joining LDS needs to be propogated across the cluster to
> every other LDS.
>
> Now, if an LDS is not configured with enough slots for
> all the LDS's that want to be in the cluster, and our
> subscribing LDS contacts that LDS for cluster info, then
> it'll get an incomplete list.
>
> However, if we can walk the cluster to discover what nodes
> are in the cluster then problem solved.
>
> This also allows the VRS to be arbitarily large, without
> defining up front how big the VRS will be.
>
> It's much easier to design and implement and gives many
> additional features and being recursive inherits the
> properties of recursive functions.
>
> I offer this list of pros and cons for discussion:
>
> Please change/comment/add/delete things :o)
>
> Pros Cons
> NodeWalk: - Easy to implement
>
> - An LDS doesn't have - Needs a route finding
> to be connected to algorithm based on the
> every other LDS returned connected graph
> to find remote and not
> directly connected LDS's
>
> - Any changes to the VRS
> structure automatically
> get propogated
>
> - Each LDS can have a - Some LDS's may only
> round trip time to each be reachable via other
> other LDS in the cluster, LDS's. This may only be
> which means they may opt a slight problem if you
> to connect to and route want to get a message to
> via the least expensive an LDS quickly. Not
> nodes. likely to be a problem...
>
> Table : - Every LDS is directly - tricky to guarantee
> visible to every other the table at an LDS
> thus direct message is complete.
> routing is immediate.
>
> - - Complicated to engineer.
> An LDS receiving an
> update from one LDS does
> not want to get the same
> update from all the other
> LDS's it is connected to.
>
> - Loss of network between
> two LDS's means that
> messages cannot pass
> between them.
>
>
> Okay brain dead now.
> Any more?
--
"First they ignore you. Then they laugh at you.
Then they fight you. And then you win." -Gandhi