vrs-development
[Top][All Lists]
Advanced

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

Re: [Vrs-development] The Design Beginning: The VRS Cluster


From: Bill Lance
Subject: Re: [Vrs-development] The Design Beginning: The VRS Cluster
Date: Wed, 3 Apr 2002 06:26:53 -0800 (PST)

> 
> 
> Questions:
> Qa) Is having a FINITE size table a bad thing?  This
> is a
>    'feature' inherited from Goldwater, so I'd like
> to keep
>    it because it works (as Goldwater will be viewing
> each
>    LDS as a Domain and needs to keep track of who is
>    available and who is not).  If a finite table
> size is
>    bad (ie cannot be worked around) then we'll have
> to
>    throw away Goldwater Domains for this project 
> :o(
>    ... This is why I've held off completing the GW
> Domain
>    rewirte ...
>    BTW, The memory requirements for GW Domain tables
> is
>    low - couple of hundred bytes per domain.  So
> this
>    finite number could be big enough so as not to be
>    restrictive in any way.... say 20-30K for 100 or
> so
>    Domains known about by a single LDS.


I also think this needs to finite, and a fairly small
number, i.e. 50, should do just fine.  

At some point in the past, I wrote a bit about the
econmomic break-even point in a VRS cluster beyond
which adding more LDS's produces more trouble than
value.  Once the VRS has enough persistance, memory
and bandwidth to do it's job (with reasonable margin),
adding more LDS's will not necessarily improve
performance, but will add to the overhead.  I don't
think that the network effect plays here.


> 
> Qb) Can an LDS join more than one VRS?  I think we
> should
>    allow this, but how do we partition the multiple
>    personalities an LDS may have?
>    This is probably not answerable now - food for
> thought.
> 

I'd think that an LDS could join different VRS's at
different times, but not as the same time.  That
would, indeed be a very difficult thing to juggle. 
What would be the use of simultaniuos connections?



> Qc) Given that multiple LDS's may be 'public', any
> service
>    discovery scheme needs to offer the IP address
> and
>    access type (SOAP/XML-RPC/Jabber message type) of
> all
>    public LDS's (just like DNS).
>    However, I'd like to see some kind of feeback
> from the
>    VRS to the SDS (Service Discovery Server(s)) so
> that
>    an LDS that repeatedly fails, or is taken out of
> the
>    VRS is no longer offered in response to a Service
>    Discovery Request.  It also means that LDS's
> added
>    to the VRS that are made public, or start off as
>    public will be automatically visible in any SDRs.
> 
>    If a standard SDS protocol is used, then this
> could be
>    achieved by a stand-alone daemon which receives
>    special VRS broadcast messages and updates the
> SDS
>    data on-the-fly.
> 
>    Service Discovery should also do some sort of
> load
>    balancing - which could be as basic as round
> robbin,
>    or fed from VRS feeback.
> 


I really don't have an opinion about the discovery
question.  

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/



reply via email to

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