Subject: still more CLID_INUSE

From: [email-masked]
Date: Thu, 18 Jul 2002 17:25:18 -0400 (EDT)

Hi again,

> So it sounds like the verifier must also be treated as a special type of
> attribute indicating the "boot instance" if a given client ID. Is it really
> assumed, or required that a new client instance will generate the same id?

That was my vague impression from the spec. (that the "id" would remain the
same across reboots and the verifier would identify a reboot so the server
could recognize a client restart and throw away old state information for
that client) I'm just trying to get a handle on what a server is supposed
to do, so I can get my implementation correct.

> I guess my assumption was that a completely new id could be generated on a
> client restart. Perhaps the server recovery is affected by that, or at
> least the timeliness of it. For locks, the server would have to hold the
> granting of new locks on the affected files until the state could be
> cleared on the existing locks (by lease expiration). This is where

That is what I vaguely understand as the B solution. ie. always reply
CLID_INUSE, which forces the client to use a new "id" after a reboot
and implies that the server gets rid of old client state via lease expiry.
(Although I think this would work, I didn't get the impression that this
 was what was intended by the RFC.)

Since the RFC doesn't have callbacks related to locks, that would be a
major change to the protocol, which is "way outa my league", so I won't
touch it.

Thanks for the comments, rick

---

From: Peter Astrand <[email-masked]>
Date: Fri, 19 Jul 2002 00:05:58 +0200 (CEST)

> and implies that the server gets rid of old client state via lease expiry.

If a server does that, I would consider it as broken (more or less). A
client should be able to re-use a clientid after reboot.

To me, the only case when it makes sense to report CLID_INUSE is when the
RPC credential changes. There is still a problem if the client wants to
change credential. I think this could be solved by adding some mechanism
to the v4 protocol to release a clientid. In this case, the client could
release the clientid with the old credential and the do a SETCLIENTID with 
the new credential. 

To minimize the problems with two clients using the same clientid, servers
can track the client IP adress and put some WARNING messages in its log
files when the IP changes, but I don't think a different IP should
generate CLID_INUSE.

-- 
/Peter Åstrand <[email-masked]>

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 18 Jul 2002 17:10:10 -0500

> to do, so I can get my implementation correct.

Yes.  This is correct. the nfs_client_id4.id stays the same between
reboots of the client and the nfs_client_id4.verifier changes between
reboots to let the server know that it must release state upon receipt
of SETCLIENTID_CONFIRM.

-- 
Spencer