Re: [Vrs-development] Scalability

[Chris Smith]

On Thursday 25 July 2002 18:09, Eric wrote:
> It's good to hear this, as it confirms my understanding of how things
> were to work.
>
> So, returning to the scalability issue -- if the list of allowed LDS
> nodes in a VRS is generally fixed; ie, we have to update the
> authentication tables to allow a new host to join ... then why don't
> we at that time also update the number of domain "slots" GW is
> configured to use?

Because it would mean shutting down each LDS, changing the config, and 
restarting.

However, I'm trying to hold of making any decisions with respect to this 
issue until we have the domain features to play with.  Then we'll be able to 
see what memory resources are required per domain entry etc.
It may be possible for an LDS to support a hundred or so domains with little 
overhead... in which case....
Also, I have this mobile-agent search and gather idea which may mean that an 
LDS is allowed to join a VRS so long as two or more LDS's have a slot for it.
(uses a multi-hop idea to get route messages to it).
However, performance wise this is not ideal.  Direct connection should be 
aimed at every time - but it might be a stopgap until people can re-config 
their LDS nodes.

> Maybe GW is configured for only 10 domains, but we want to add an 11th
> LDS node to the VRS.  So we add the 11th computer to the auth tables,
> and change the GW configuration use 11 slots...  This seems a lot
> easier than keeping a limited number of slots and swapping domains in
> and out using some other-host discovery mechanism.  And I honestly
> don't think it's a scalability problem to keep a complete list of all
> hosts, unless we're looking to build VRS's with tens of thousands of
> nodes and we want it to run on 386's with 16 megs of memory...

Ah I should have read ahead.
I see you're with me on the scalability points.  I think the key is to 
remember that a VRS is generally a small membership, and thus controllable - 
including the LDS sizing (or thats the premise at the moment).

Chris

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