[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Vrs-development] Scalability
From: |
Chris Smith |
Subject: |
Re: [Vrs-development] Scalability |
Date: |
Mon, 29 Jul 2002 10:12:27 +0100 |
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
- [Vrs-development] Scalability, Chris Smith, 2002/07/22
- Message not available
- Re: [Vrs-development] Scalability, Chris Smith, 2002/07/22
- Re: [Vrs-development] Scalability, Eric Altendorf, 2002/07/26
- Message not available
- Message not available
- Re: [Vrs-development] Scalability, Ian Fung, 2002/07/26
- [Vrs-development] Dynamic GW domain table, Eric Altendorf, 2002/07/26
- Re: [Vrs-development] Dynamic GW domain table, Chris Smith, 2002/07/29
- Re: [Vrs-development] Dynamic GW domain table, Eric Altendorf, 2002/07/29
- [Vrs-development] Meeting: Saturday 16:00UTC?, Eric Altendorf, 2002/07/26
- Re: [Vrs-development] Scalability, Chris Smith, 2002/07/29
- Message not available
- Re: [Vrs-development] Scalability, Chris Smith, 2002/07/29
- Re: [Vrs-development] Scalability,
Chris Smith <=