[Top][All Lists]

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

Re: [Vrs-development] Mobile Agents

From: Chris Smith
Subject: Re: [Vrs-development] Mobile Agents
Date: Wed, 24 Apr 2002 16:59:29 +0100

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?

Chris Smith
  Technical Architect - netFluid Technology Limited.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk

reply via email to

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