Subject: seqid in SETCLIENTID

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 3 Jan 2000 08:21:18 -0800

Does anyone understand why this is necessary.

In reviewing draft-03, I had been confused about this
and assumed, that it came in in draft-03 with Mike
Eisler's SETCLIENTID_CONFIRM stuff.  In fact the
seqid in SETCLIENTID appears in drafts 01 and 02 as 
well, although it isn't mentioned in the sections
that describe Client ID (8.2.1 in draft-03) or 
Sequencing (8.2.4in draft-03), in any draft.

Given that a client is going to send exactly one
SETCLIENTID to a server, I don't understand why
we have a sequence.  He will send another one,
when he thinks the server has rebooted, but
if the same rules apply as for other sequence 
id's, then the sequence should be reset at this
point.  So, the seqid will always be zero and
why is it there?  Also, if the normal sort of
seq id logic applies on the server, then when 
it gets a new SETCLIENTID, and it has zero for 
the seq-id and the previous SETCLIENTID was 
zero, then it should be ignored, but we most
certainly don't want that to happen if the 
client just rebooted.

If you have a delayed retransmission within a
conversation between a client-instance and a
server instance, the fact that the verififier
is the same will allow to prevent any bad effects.
If the delay is across one or more client reboots
that SETCLIETID_CONFIRM solves the problem if you
have it but seqid adds nothing.

Am I missing something?

If we really need this in the spec, then it has
to explained somewhere.  This is a sequence space
which is different from all the others, which are
lockowner-based, so its rules and logic need to be 
set out somewhere.  Right now they aren't.

Perhaps somebody has a pointer to an explanation of 
what this is for.

---

From: Mike Eisler <[email-masked]>
Date: Thu, 6 Jan 2000 14:05:47 -0800 (PST)

> set out somewhere.  Right now they aren't.

I didn't notice that sequence numbers were per nfs_lockowner. So
Dave is right.

If caller doesn't set the confirm boolean to TRUE, then very bad things will
happen if the seqid isn't something like an absolute time stamp. If there is
no seqid present, then there will be frequent instances of the a client's
locks getting blown away. Rather than deal with separate sequence spaces, I
think it would be simpler to make SETCLIENTID confirmation a mandatory feature
... i.e. remove the confirm boolean from SETCLIENT4args, and the associated
sequence numbers from SETCLIENT4args, and SETCLIENT_CONFIRM4args.

BTW, the OPEN confirmation stuff in -03 of the specification doesn't appear to
match my intent. The confirmation step is only needed when the server has no
record of the client's clientid. It looks to me that OPEN4resok always returns
an open confirmation cookie. This isn't desirable due to the extra round
trips.

As a result of some e-mails Dave N. sent me over the holiday break, I've
re-thought the OPEN confirmation stuff a bit. Since a replayed OPEN is only
a danger when the server has freed the record of the client's clientid,
I think that simply adding a new error code:

        NFS4ERR_CLIENTID_NOT_SET

to the list that can be returned by OPEN will suffice. In that case,
the client simply sends a SETCLIENTID operation  and once the clientid set up
is done, re-issues the OPEN with a seqid of zero.

This way OPEN is simpler, and we get rid of OPEN_CONFIRM.

	-mre