vrs-development
[Top][All Lists]
Advanced

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

Re: [Vrs-development] Authentication


From: Chris Smith
Subject: Re: [Vrs-development] Authentication
Date: Mon, 7 Oct 2002 18:45:33 +0100

On Friday 04 October 2002 19:36, Ian Fung wrote:
> aahhhh.... I'm in class right now, so I have some time to actually write an
> email. I hear ya chris, trying to not fail out of college over here =).
>
> ".. it involves LDSs pooling connections to the most frequently accessed
> remote LDSs."
>
> I don¹t really know what that means... I have an idea though, well I think
> I already talked about it...but let me reiterate. I think it *might* be
> what you have in mind.
>
> so let's say you want each LDS to have a hard limit for the number of nodes
> it can store and that you don¹t want to have all/most discoveries be
> dynamic. so in my mind that kinda lends itself to the following situation.
> you have LDSs with a finite max capacity in the routing table. in order to
> support an arbitrary number of links, every LDS can't contain a list of
> every page, which is ok. so the idea is to say have an LDS contain routes
> to links that it actually needs. I am assuming that LDSs will organize
> themselves in a sort of social network where there exist several strongly
> connected components (SCCs). and maybe there will be weak links between
> these SCCs. so an example is we have a VRS network. There are LDSs that are
> involved in running a distributed computation. so they form a SCC cause you
> would imagine that they need to be connected to each other to coordinate
> their computations. then there is another SCC that will say be a webserver.
> so they will serve whatever and are all connected to each other. the "weak
> links" that I mentioned before will represent say an LDS in the distributed
> computing SCC who has a route entry to a LDS in the webserver SCC.

Well there are lots of possibilities:

1. An LDS connects to a subset of all the LDS's in the VRS.
   It knows about ALL the LDS's in the VRS, but only has direct connection
   to a finite number of them.
   This means the RM needs to keep track of ALL segments of data in the
   repository.
   Messages are routed to the next-nearest LDS for forwarding if a direct
   connection is not available.
   The connection list is modified if frequent 'forwards' are required.

2. An LDS is connected to a subset of all LDS's in the VRS.
   It does not know about any other LDS's in the VRS.
   The RM only needs to keep track of it's own segments of data.
   There is no intelligent modification of connection-list possible, as the
   LDS does not know about other LDS's (other than those to which it is
   connected).

and so on, through combinations of the above.
I favour 1. but don't know how this impacts the RM design as all the CM needs 
to be able to do is provide dynamic routing and multi-hop forwarding, the 
data segment tracking is up to the RM.


We've a cross-over here Ian.  What are your thoughts on the above?

Chris
   
-- 
Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "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]