Subject: more on CLID_INUSE for setclientid

From: [email-masked]
Date: Mon, 15 Jul 2002 17:58:45 -0400 (EDT)

Well, the more I think about it the more I go around in circles. (I basically
agree with Dave that the clients really need to try to get nfs_client_id4.id
unique.)

Here's how it seems to me...
- If two clients do end up with the same nfs_client_id4.id, they can play
  a really nasty game of music chairs. One does setclientid, then the other
  does setclientid, replacing the clientid on the server. The first one's
  setclientid_confirm fails, it does setclientid again, replacing the second's
  clientid, and so on, and so on.

  The only thing that stops this is the server replying with the CLID_INUSE
  error.

So, the only really safe thing for the server to do is to reply CLID_INUSE
whenever the same nfs_client_id4.id as a current one shows up, BUT...

--> then clients get CLID_INUSE after a reboot or retransmit of a setclientid
    op rpc and the server can't throw away the old clientid state until the
    lease is up.

Again, similar to what Dave said, I can't see a good solution to this.

I think, for now, my code is going to paranoid and reply CLID_INUSE unless
all of, the same principal/user, callback address and return IP# are the
same as what was given in the setclientid request that allocated the clientid.
(This way, the verifier still does tell the server about a client reboot/
 retransmit, but minimizes the chance of "musical chairs" if two clients
 do somehow get the same nfs_client_id4.id.)

This does imply that clients that change their IP# won't be recognized as
rebooted (which means their old state will hang around unless the lease is
up) and that multiple clients on the same machine will have to be careful
about creating a unique id, but??

Just my thoughts, rick

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 17 Jul 2002 18:51:15 -0500

>  do somehow get the same nfs_client_id4.id.)

Note that the solaris client upon reboot will have different callback
information.

-- 
Spencer