Subject: RE: Another sequence id issue

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 15 Nov 1999 09:58:46 -0800

> SETCLIENTID's arguments are:
> 
> struct cid {
>              opaque          verifier[4];
>              opaque          id<>;
> };
> 
> Rather than add a server id, if the client uses a unique 
> verifier/id pair in
> the SETCLIENTID request to each unique server address, this 
> forces the server
> to return unique clientds. This suggests that a fixed length 
> 4 byte verifier in
> the SETCLIENTID arguments is inadequate. I suggest making it 
> variable length,
> and adding appropriate verbiage to the specification to account for
> the scenario you described.
 
Unless I'm misunderstanding what you are proposing I don't
understand why the 4-byte verifier is inadequate.  If I
simply use the id to present different identifications when
I am not sure if I am talking to two servers or the same
server, then I will get two different clientid's and in
the case in which I am really talking to one server, he
will think he is talking to two different clients so that
when I construct my sequence id's, I will construct them
on the basis that I am one client talking to two different
servers (and so have separate sequence id streams), which
will work fine if I am in fact talking to one server since
he will think he is talking to two different clients.
I think this will work although it seems positively 
Pirandellian :-).

If I do this, why would I not use the same verifier for
each id?

---

From: Mike Eisler <[email-masked]>
Date: Mon, 15 Nov 1999 10:23:38 -0800 (PST)

> If I do this, why would I not use the same verifier for

You could use a unique id, but it might complicate some
implementations, such as UNIX clients that want to store an
a process id in the id field. 

A variable length verifier that the was constructed with 4 bytes of
stuff from the client plus the server's IP address, might simplify
implementation. 

	-mre

---

From: Neil Brown <[email-masked]>
Date: Tue, 16 Nov 1999 13:54:54 +1100 (EST)

> a process id in the id field. 

I'm a bit confused by this.
Are you thinking of a user-process-level client?  Such a client would
need to identify both the host and the process (at least) in the
nfs_client_id4.id field. Adding the server (name or address) shouldn't
be much burden.

Or is there some confusion with the nfs_lockowner4.owner field which
may well identify a process id, but is quite separate from the
nfs_client_id4.id field.

NeilBrown

> stuff from the client plus the server's IP address, might simplify

The draft says:

   Verifier  A 32-bit quantity generated by the client that the server
             can use to determine if the client has restarted and lost
             all previous lock state.

I think this is a clean definition for the verifier, and that adding
server information would polute it.

> 	-mre

NeilBrown

---

From: Mike Eisler <[email-masked]>
Date: Tue, 16 Nov 1999 03:28:22 -0800 (PST)

Neil,

You are absolutely correct. A fixed size verifier on SETCLIENTID is
fine.

	-mre