Re: [Vrs-development] Scalability

[Chris Smith]

On Monday 22 July 2002 16:00, Ian Fung wrote:
> so two things, scalability, and multi-hope routing. i am not sure how
> the networking is handled/supported in gw, but we should *definitely*
> have support in the network layer/manager to support ad-hoc routing
> protocols (AODV, TORA, DSDV, DSR, etc). 

GW has it's own protocol.  If GW on one machine needs to communicate with GW 
on another machine it just does so, directly because it has been configured 
to know about that other machine and the resources it provides.
GW applications spanning multiple machines act as a single application.
It's kind of like the Borg in STTNG.

I have I hunch that you're viewing the messages passing between LDS's as 
being internet-protocol type messages :o)
They're not as there is a significant amount of synchrous dialogue that needs 
to take place during a single message transfer.
There's nothing to stop us sending general messages via other protocols 
(internet) between LDS's - but then you have to ask why you're using a 
middleware.

> the second thing is scalability. i dont see any reason that we should
> assume any finite number as an upper bound for the number of LDS's that
> will play nicely before performance degrades drastically. algorithms for
> providing scalability is a whole different issue. we can do without them
> in the first phase. the important thing is to keep in mind they are
> needed and have a mechanism by which to add them to the network
> manager/gw.

Okay, an example (just like the one Bill gave me... :o)  )
All the members of this mailing list could set up a VRS, each of us running 
an LDS.  Thus we'd have a VRS consisting of (currently) 5 or so LDS's.
As new members join the list they may request participation in the VRS 
cluster.  Some admin or other would update the authentication tables 
(distributed by the RM across the VRS) to allow that user to join.  The user 
then start's up their LDS and subscribes to the VRS - they authenticate 
successfully and hookup.
Thus the whole VRS membership is controlled and moderated.
If one of the participants goes offline, then that doesn't matter because 
their resources are cloned and distributed across the other LDS's in the VRS.
If someone want's to leave perminently, then that's fine too - the admin just 
removes their authentication details.

You don't have to be an LDS owner to be able to access resources offered by 
the VRS.  So long as a 'publicly accessable' network server (HTTP/Jabber or 
something) is provided on at least one LDS then external users will be able 
to access the resources.

Even if we set a VRS cluster comprising our members, someone at MIT may set 
up their own distinct VRS comprising whoever they want.

The VRS is not a single, generic, arbitary, identityless cluster of machines.

..... however, an external user sees the VRS as a single webservice provider 
(the fact that it is multiple machines is hidden) the external user would 
perform some sort of web-service discovery to locate a resource.  
They would be returned the address of an LDS (or LDSs plural) of the VRS 
nodes that have public HTTP/Jabber/etc servers on them that can satisfy that 
webservice request.

So requests for several resources may require the support of several VRS's, 
but those VRS's are not in any way related.


That was tricky!  I'm trying to get inside your head Ian to see how you're 
seeing things.  How am I doing? :o)

Chris

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