Re: [Vrs-development] The Virtual Remote Server Functionality

[Chris Smith]

On Friday 08 February 2002 17:13, Bill Lance wrote:

> Level I - Static File Server
> This level of functionality provides basic, static
> file services.   It is based on components built into
> the LDS, and on a simple data files stored in the
> Repository.  The basic LDS component here is the
> Apache server.  It can provide static html page
> services and ftp file download services.   Other
> service modules, such as smtp and pop may be
> incorporated in deemed appropriate.

I assume you're refering to the service access modules.  ie HTTP access being 
provided by Apache, with others defined on a need basis.
The static content to which you refer comes from within the invoked 
webservice not traditional static resources to which Apache has access??


> Level II - Virtual Machine based Component Server
> The next level adds programmable functionality with a
> Virtual Machine  (VM) component in the LDS.  The VM
> executes an intermediate byte code file. Together with
> external tools that can produce such code and package
> it with data into Executable Object Datasets,
> customized component webservices can be exposed to the
> net and fulfilled by the VRS.  The Pnet project is the
> idea candidate for providing these services.

Yep.  The webservice equivalent of inkoving a CGI at a webserver.

> Level III - Encapsulated total Server System
> The last level is the most ambitious of the targets.
> It depends on the Repository being able to store and
> retrieve a total hiearchial file system that can
> include not just data files, but native executables as
> well.  It also depends on being able to run those
> executables in a sufficently stronge sandbox to meet
> the security and privacy requirements of the system

Hmm.  I'm slightly concerned on how you manage 'native' exe's.  Surely you'd 
want them to be in bytcode, as you can't guarantee the platform on which 
they'd be deployed.
You're quite right in wanting 'controlled' native exe's on controlled 
machines.  These resources would NOT be distributed as part of the VRS data 
set, but anchored to the machine on which they were deployed.
How you sandbox these is interesting - you could do the CGI trick of chroot 
and ulimit etc, but you have the fork-exec server hit, which is not nice.  
Some sort of 'ready to run' state would be good - perhaps done through a 
cache of most recently invoked executables.  ie, once an exe has run it 
lingers for a short time ready to accept another request.  The time window 
during which it lingers should be based on the frequency of requests for it.
But this is very complicated.  Very complicated.  You can abstract the whole 
'how we get an exe and run it' into a box and TRY and build in this kind of 
optimisation later - but it is very complicated!!

> The last level is the new one.  The more I think about
> the file system, the more possible it seems.  How
> practical it'd be .. especially in terms of response
> time, is going to be interesting to see.

> User-mode Linux may also point the way to running the
> entire server environment in a secure shell,

Certainly a consideration in any case.

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