Subject: setclientid

From: [email-masked]
Date: Mon, 8 Jul 2002 17:08:01 -0400 (EDT)

I've just taken a stab at implementing this and have run into the following.

How is the server supposed to distinguish between a client doing a retry
of setclientid and different clients doing a setclientid with the same
"id". (The latter is supposed to get the response NFS4ERR_CLID_INUSE
whereas the former should get an NFS_OK with the clientid?)

It looks like the Univ. of Michigan server differentiates between these
two cases by looking at the source IP# (not in the callback info in the
request, but from the transport layer). Does this sound right, or should
it use the callback net address info or ??

The above is referring to the case where both the "id" and "verifier" match
one that is already in the server's list. (The case of "id" matching and
"verifier" not matching is the reboot case, right?)

Thanks again in advance for any help, rick

---

From: Peter Astrand <[email-masked]>
Date: Mon, 15 Jul 2002 10:38:39 +0200 (CEST)

> it use the callback net address info or ??

I asked a similiar question a few months ago, see 
http://playground.sun.com/pub/nfsv4/nfsv4-wg-archive/2002/0085.html. 

I have a general feeling of that SETCLIENTID is more broken than it has to
be. I think it's strange and awkward that CLID_INUSE cannot be triggered
from one machine, even though it's possible to run several user-level
clients on the same host. Using the source IP from the transport layer is
also strange. Doesn't this mean that if the client is changing IP and then
does a new SETCLIENTID, then the server will respond with
NFS4ERR_CLID_INUSE?

Is it really necessary for the server to store the client adress as a part 
of the client information? Too me, it seems sufficient that the server 
stores nfs_client_id and principal. CLID_INUSE could be reserved only for 
the case where the principal does not match. Or have I forgotten 
something?

Btw, if the client sends a CLIENTID with the same nfs_client_id but a 
different cb_client4, should the server then update the callback 
information? I suppose this will be necessary if the client wants to 
change IP without having to release all state. 

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