Setclientid / Definition of client

[Trond Myklebust]

On Mon, 2006-12-04 at 12:00 -0500, J. Bruce Fields wrote:
> On Mon, Dec 04, 2006 at 11:35:23AM -0500, Trond Myklebust wrote:
> > On Mon, 2006-12-04 at 11:25 -0500, J. Bruce Fields wrote:
> > > Not necessarily--multiple users should be able to use the state
> > > established by a setclientid performed by a single user.  But of course
> > > if that single user goes away, then you're left with no way to
> > > reestablish the state that was held under the clientid established by
> > > that user.
> > 
> > Under what circumstances is that a problem? Normally, we just RENEW, and
> > if that fails, we assume we will need to re-establish state from
> > scratch.
> 
> I don't think we can guarantee the ability to hold onto that first
> user's credentials for as long as some second user might be holding some
> state.  So the problem would be something like:
> 
> 	1. User 1 gets some state, and we establish clientid with
> 	   user 1's credentials.
> 	2. User 2 gets a lock on file foo.
> 	3. User 1 goes away, destroys any credentials.
> 	4. We're unable to renew the state, so lose user 2's lock.
> 
> Except, I'm wrong--the spec allows us to renew using user 2's
> credentials, doesn't it?  We may lose the ability to invalidate our
> previous state on a client reboot (but presumably letting it just expire
> isn't a big problem in that case).

Yes. We're renewing state using the credentials of some user that holds
open state.

> That does give the first user the ability to revoke any other user's
> locks or opens, though.

In theory, yes.

> What about a situation like this:
> 
> 	1. User 1 opens a file, then closes it and goes away.  Noone
> 	else is holding any state, so we stop renewing.
> 	2. User 2 opens a file.
> 
> If 1 and 2 happen close enough together, then the server might still
> consider the old client instance valid and reject user 2's setclientid.
> Or is the server required to allow the setclientid if the old instance
> doesn't hold any current state?  OK, it'd make sense to do that.

Our client will always try a RENEW first. If that fails, then we
setclientid, if that fails, we change the client identifier string.

Cheers,
  Trond