Subject: [nfsv4] more re: server recent request cache

From: [email-masked]
Date: Mon, 17 Nov 2003 15:07:54 -0500 (EST)

Dave, why didn't I think of this. Good stuff.

>    Comparison of the tags or a hash thereof.  Since the reply will
>    contain, normally, the request tag value, the tag for the request 
>    in the case could be compared against that for the putative 
>    retransmission with rejection on a mismatch.  Even if you don't
>    save the tag (too large or something), you can still save a hash 
>    of the request tag in the request cache entry header and compare
>    that to the hash of the tag for the incoming request.

Yep, the tag or a checksum/hash on the tag or on the first N bytes of the
NFS XDR (but not RPC header), maybe along with the length of the request,
sounds good to me. (Unfortunately, the checksum for Integrity and Cipher from
decryption will change for retries, so they can't be used. However
calculating one more simple hash/checksum isn't a lot of work.)

[other good suggestions snipped]
The things I had thought of were:
- received on same TCP connection or a different one connected before the
  one the original request was received on --> a miss
- if the cached request is associated with a reply being held because it is
  the reply for a current seqid# (Open,...), then play it safe and consider
  it a miss until the same seqid# is recognized when seqid# checking happens,
  since you know for sure then

> possible problem is false negatives.  Can anybody conceive of situations 
> in which a request should validly be considered a re-issue and not match on 
> any of the discriminators above? 

Unless clients choose to retry with a different tag for some reason, I
can't think of anything, so long as you're looking at the unencrypted
NFS XDR and not the RPC header (GSS authenticator/verifier will change).
(Encrypted data might change, if the data is encrypted during send instead
of before, due to the random confounder. If fact I might try and argue that
the encryption should be done for each retry, so the random confounder does
change and the current key for the context handle is used?)

Thanks for the good ideas, rick

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