[cap-talk] KeyKOS, EROS, CapROS keyInfo/databyte (was: Re: EQ, MyCap? review)

[Jonathan S. Shapiro]

On Tue, 2008-02-12 at 19:54 -0800, Charles Landau wrote:
> To add to what Eric and Jonathan have said: you could in principle do 
> what I think you are suggesting, which is to use new keyInfo values 
> for new objects, and retire keyInfo values for rescinded instances. I 
> don't recall any case where we did so, for two reasons.
> (a) You need 2**8 or 2**16 bits to keep track of the valid keyInfo values.
> (b) If clients allocate all keyInfo values and rescind all but one, 
> you still need to keep the server process around...

There is a third issue. The stale key info values are not stale in the
eyes of the primitive invocation mechanism -- only in the eyes of the
server. In the presence of misbehavior or bugs, the server may need to
devote arbitrary work to sending UnknownRequest responses (or
equivalent) to invocations issued on these "stale" capabilities.

One advantage of the indirection object (whatever it is called) is that
the indirection object itself can be destroyed. Once it is severed, the
service will never see such bad requests.

shap