[Vrs-development] Service Manager free-style

[Eric Altendorf]

Sorry for the delay in my response -- very spotty internet service at the 
moment.


On Thursday 11 April 2002 16:15, you wrote:
> The Services Manager does the real work of the VRS. It
> provides net services to the network, but from a
> managed sandbox.  Think of it as a complete network
> server, HTTP, SMTP, FTP, JABBER, J2EE, whatever. The
> protocols supported are modular.  It most likely will
> incorportate existing GPL compatable software such as
> apache, wuftp. etc. wrapped into a secured shell.

OK, I'm going to ask a dumb question here -- will these services be available 
on their standard respective ports (in which case the services manager sounds 
a lot like xinetd...?), or will it offer connections via a special services 
manager port, with its own protocol, unwrapping each request and dispatching 
it to the appropriate server?

And regarding the services/protocols supported -- do we intend on using 
stand-alone independent server processes (e.g., a standard Apache process)?

> There are several basic questions here I think.  The
> first is how to organize the software components in an
> LDS to support this function.  The second is to insure
> that all Cluster LDS nodes have the same set of
> services.

Well, this may be a minor point, but I'd argue that we not require each LDS 
node to support the entire set of services.  If someone has a computer they 
want to donate to an LDS cluster, but they for one reason or another can't or 
don't want to run an EJB server, they shouldn't be prevented from joining and 
offering the other services.  Or maybe a node has lots of disk space but no 
spare CPU cycles, and it could be donated for storage but no services.  
Besides, nodes may experience temporary failures of certain services (e.g., 
Apache gets misconfigured and won't run) and that shouldn't interfere with 
the node's operation in providing other services.

Probably connections to an LDS node which does not support (at that moment) 
the requested protocol should simply be redirected to a node that does. 


This suggests to me a layering separatation.  The VRS (as I see it) 
accomplishes two interesting things -- providing distributed and secure file 
storage, and providing services (through multiple LDSnode-to-Internet 
connections) which operate based upon the contents of the files.

Incidentally, the former sounds temptingly like the Andrew File System...?  
Anyone else familiar with that?  I wonder if there's any work there we could 
use...

Anyway...So...this is kind of how I see it.  Each and every LDS node on a 
cluster runs a service manager, which (somehow) routes requests to an 
appropriate server module/process (either on a local machine, or redirected 
to another LDS node should it not be available on the local machine).  That 
server module/process accesses files off the distributed file system, 
processes them as necessary, and then 
returns the response to the client.  (A future enhancement could include, for 
services that require trivial processing like uncompressed ftp downloads, 
client software that would allow multiple simultaneous connections to 
multiple LDS nodes to speed file transfers...but that's kind of a separate 
thing.)

I guess the other thing the service manager should do is manage the list of 
other LDS nodes currently available.  That includes talking to other 
currently-available nodes to authenticate new nodes when those nodes come 
alive and attempt to join the cluster...no?


How far off base am I here? :-)

Eric

-- 
"First they ignore you.  Then they laugh at you.
 Then they fight you.  And then you win."             -Gandhi