Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!mcsun!corton!imag!mururoa!danton.osf.fr!condict
From: condict@danton.osf.fr (Michael Condict)
Newsgroups: comp.os.misc
Subject: Re: More questions about Amoeba and Capabilities
Message-ID: <1258@mururoa.imag.fr>
Date: 18 Jun 91 11:09:52 GMT
References: <2623@amix.commodore.com>
Sender: news@imag.fr
Reply-To: condict@danton.osf.fr (Michael Condict)
Organization: OSF Research Institute
Lines: 59

In article <2623@amix.commodore.com>, skrenta@amix.commodore.com (Rich
Skrenta) writes:

> Question #1:
> 
> An Amoeba server is only listening on a port if it is blocked in a
> get_request(port, ...) call.  Does this mean that if the server runs
> out of threads executing get_requests that the service appears to vanish
> to prospective clients?  A client trying to locate the service port might
> fail just because the service is busy.  How is this dealt with in Amoeba?
> 

The server is expected to always have at least one thread blocked in a
get_request.  Even if it doesn't, the client won't fail until and unless
timeout occurs in its transaction before any of the threads of the server
get back to the top of the loop and take another request.  The client can
set any desired timeout in each transaction.  The difficult part is deciding
on a reasonable timeout.  When I worked on Amoeba, we were coming to the
conclusion that 1 to 2 seconds is adequate for any well-designed server on a
local area network.  Note that this timeout affects only the wait for a server
to take a request.  It does not specify how long the server is allowed to
take to carry out the request.  Thus a server can always avoid client timeout
by using the standard technique of invoking a new server thread whenever all
server threads are busy.

The hairy issue is "service" timeout.  Currently, Amoeba does not allow the
user to limit the amount of time the server is given to carry out a request.
Once a malicious server takes your request, you are blocked until it decides
to let you proceed.  I argued that Amoeba can never be a robust, secure
system until service timeout is implemented, but I don't know if they have
it yet.

> Question #2:
> 
> The bullet file server returns a capability when you ask it to create a
> file. . . .
> Presumably you're supposed to add this capability to a directory or otherwise
> responsibly manage it.  But what if you "lose" it?
> . . . 
> The capability is not stored anywhere, but the bullet file server doesn't
> know this.  There is an unreferenced file on the file server with no
> way to "garbage collect" it.
> 

This one is easy, really.  It is required that any object you want to
remain around permanently be "touched" periodically, meaning the STD_TOUCH
operation must be performed upon it, to indicate interest in the object.
If you enter the capability in the directory graph, this will happen
automatically, because the object manager that does garbage collection
first traverses the directory graph, touching everything it sees.  If you
don't enter it into a directory that is reachable from the "super" root
directory, you are responsible for periodically executing something that
will touch it.  Otherwise it will be destroyed by the object manager within
24 hours or so (this is adjustable).

Michael Condict
European Research Inst.
Open Software Foundation
Grenoble, France