Subject: [nfsv4] error in EXCHANGE_ID

From: "Mike Eisler" <[email-masked]>
Date: Tue, 29 Apr 2008 16:35:31 -0700 (PDT)

5.  Client Restart

          If EXCHGID4_FLAG_UPD_CONFIRMED_REC_A is not set, and if the
          server has the following confirmed client record, then this
          request is likely from a previously confirmed client which has
          restarted.

          { ownerid_arg, old_verifier_arg, principal_arg,
          old_clientid_ret, confirmed }

          Since the previous incarnation of the same client will no
          longer be making requests, once the new client ID is confirmed
          by CREATE_SESSION, lock and share reservations should be
          released immediately rather than forcing the new incarnation
          to wait for the lease time on the previous incarnation to
          expire.  Furthermore, session state should be removed since if
          the client had maintained that information across restart,
          this request would not have been sent.  If the server does not
          support the CLAIM_DELEGATE_PREV claim type, associated
          delegations should be purged as well; otherwise, delegations
          are retained and recovery proceeds according to
          Section 10.2.1.

          After processing, clientid_ret is returned to the client and
          the client record is replaced with:

          { ownerid_arg, verifier_arg, principal_arg, clientid_ret,
          unconfirmed }

-----------------------

The problem is that the IMPLEMENTATION section says to replace the
confirmed record with an unconfirmed record.

But the spec also says that the client ID's state is not to be removed
until the clientid_ret is confirmed by CREATE_SESSION.

There are multiple ways to deal with this, but in the interest of
not describing an implementation with a complex state diagram, I
propose changing:

          After processing, clientid_ret is returned to the client and
          the client record is replaced with:

          { ownerid_arg, verifier_arg, principal_arg, clientid_ret,
          unconfirmed }

to something like (with apologies to those who hate quantum mechanics and
cats that are alive and dead at the same time):

          After processing, clientid_ret is returned to the client and
          the this client record is added:

          { ownerid_arg, verifier_arg, principal_arg, clientid_ret,
          unconfirmed }

          The previously described confirmed record exists, and thus
          the same ownerid_arg exists in both a confirmed and unconfirmed
          state at the same time. The number of states collapses to
          one once the server receives an applicable CREATE_SESSION or
          EXCHANGE_ID. If server subsequently receives a
          successful CREATE_SESSION that confirms clientid_ret, then
          the server atomically destroys the confirmed record and makes
          the unconfirmed record confirmed as described in
          <xref target="OP_CREATE_SESSION_IMPLEMENTATION" />.
          If the server subsequently receives an EXCHANGE_ID with the
          client owner equal to ownerid_arg, one strategy
          is to simply delete the unconfirmed record, and process the
          the EXCHANGE_ID as described in the entirety of
          <xref target="OP_EXCHANGE_ID_IMPLEMENTATION" />.

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Robert Gordon <[email-masked]>
Date: Tue, 29 Apr 2008 20:11:07 -0500

I agree, the change makes sense;

On Apr 29, 2008, at 6:35 PM, Mike Eisler wrote:
{cut}
>          the this client record is added:
Nit: -----^^^ "then" or delete 'the' ?

---

From: Robert Gordon <[email-masked]>
Date: Tue, 29 Apr 2008 20:18:51 -0500

Actually, shouldn't this be..

On Apr 29, 2008, at 6:35 PM, Mike Eisler wrote:

>                                    The number of states collapses to
>          one once the server receives an applicable CREATE_SESSION.
>          If server subsequently receives a successful CREATE_SESSION
>          that confirms clientid_ret, then the server atomically
>          destroys the confirmed record and makes

that is i removed the EXCHANGE_ID from the first quoted sentence.

so, destruction (of the confirmed record) always occurs at the
time of CREATE_SESSION.

Robert..

---

From: "Mike Eisler" <[email-masked]>
Date: Tue, 29 Apr 2008 19:13:34 -0700 (PDT)

> so, destruction (of the confirmed record) always occurs at the

Let's say I have a confirmed record. I get a EXCHANGE_ID that results
in the client owner having both an unconfirmed and the
confirmed record from the previous sentence.

Before CREATE_SESSION arrives, another EXCHANGE_ID arrives. So
do I potentially go from two states to three? My proposed
text is that when the second EXCHANGE_ID arrives the existing
unconfirmed record goes away. So I go from two to one state,
and potentially go to two again depending on what the arguments
to EXCHANGE_ID are.

In other words, if you don't like my text, give me text that
tells me what to do if I get an EXCHANGE_ID instead of
a CREATE_SESSION. :-)

Preferably simple text.

---

From: Robert Gordon <[email-masked]>
Date: Tue, 29 Apr 2008 23:59:43 -0500

On Apr 29, 2008, at 9:13 PM, Mike Eisler wrote:
> do I potentially go from two states to three?

no! :)

> My proposed text is that when the second EXCHANGE_ID arrives the  
> existing

We agree.

I wasn't able to figure out how we'd ever transition from
confirmed_old_record + new_unconfirmed to just new_unconfirmed'
via an EXCHANGE_ID.

I was thinking that the only scenarios i would expect to match
for another EXCHANGE_ID would be "4. Replacement of unconfirmed"
(just replace the unconfirmed record).  I had failed to think
that a client could "6. Update" (in which case i'd eventually
garbage collect the unconfirmed record)..

(i might notify the EXCHANGE_ID police tho' if a client did anything
  other than "4.".. a clear excuse for NFS4ERR_NAUGHTY_CLIENT)

> tells me what to do if I get an EXCHANGE_ID instead of

I think you already did..

> Preferably simple text.

Leave it as is.. :)

-- 
Robert.