Re: seqid in SETCLIENTID

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Mike Eisler (mre@eng.sun.com)
Date: 01/06/00-04:05:47 PM Z


Date: Thu, 6 Jan 2000 14:05:47 -0800 (PST)
From: Mike Eisler <mre@eng.sun.com>
Subject: Re: seqid in SETCLIENTID
Message-ID: <Roam.SIMC.2.0.6.947196347.28940.mre@eng.sun.com>

"Noveck, Dave" <dave.noveck@netapp.com> writes:

> 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.

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


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:59 AM Z CST