Re: [Vrs-development] Authentication

[Ian Fung]

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.

so of course there is no guarantee that those two SCCs are connected at all.
I think between general usage, the fact that a LDS need a point of entry,
and also studies in general social networks (www), this is not a bad scheme.
If all else fails, a node can just broadcast a discovery. =\. we may need to
modify and add some hacks like a hub LDS that is guaranteed to contain one
LDS from each SCC. Then again there is the problem of recognizing what
exactly consist of an SCC.

aside from all those questions which are mostly premature, I think having a
finite number of routes in each LDS but having LDSs with different route
entries will serve us well.

is that what you had in mind?

sorry about the incoherent rambling but I didn¹t get a chance to collect my
thoughts. hopefully you got what I was trying to say. any questions will be
great. 

so this is what I think I'm going to do, try to define a structure for
things we need to solve and get the new webpage made.

ok, I think the prof is saying something I need to know. later

-alias

On 10/4/02 12:48 PM, "Chris Smith" <address@hidden> wrote:

> 
> Been having a bit of a ponder on the old 'infinite' cluster size issue. I
> have a plan, and it involves LDSs pooling connections to the most frequently
> accessed remote LDSs.  That way we can stay within our system imposed 'max
> connections' whilst benifiting from a bunch being 'keep-alive'.  This is a
> departure from GWs current design, but looks like it is easy to achieve. Rah!
> 
> So, some questions for yah:
> 
> When an LDS wants to talk to another LDS it will need to authenticate in some
> way (We can't have just *any* old LDS taking part in the VRS anonymously!).
> 
> So I'm thinking that perhaps an LDS that asks to join a VRS initialy gets a
> certificate signed by the VRS moderator.  This certificate will be checked
> whenever a new connection is established and rejected if it was not signed by
> the appropriate agent (basically by checking the RootCA perhaps...).
> 
> 
> What are peoples views on this?
> Any other suggestions?
> 
> Goldwater is designed to support various authentication mechanisms as is,
> though there is no code behind any of them yet.
> 
> I'm also desperately trying to get pNet linked into Goldwater so we can start
> using C#... and writing documentation for GW.... and holding down a day job
> which is eating up my time..... arrrrrrrrrggggggggggggg :o)
> 
> When I've got the pNet skeleton started, it should be straightforward for
> people to extend GWs pnet features as and when required.
> 
> Cheers.