Subject: sequence id logic -- Silence is no longer golden

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 21 Oct 1999 19:15:32 -0700

The spec talks about silently ignoring lock requests when the per-
lockowner sequence id does not match.  (I don't have the precise
text since my hardcopy version of the spec is packed and I got a
Page Not Found for the one on www.nfsv4.org), but I believe it
is supposed to silently ignore the request if the sequence id in
the request is either less than the last one processed or greater
than the last one processed plus one.  

I assume that this was written before COMPOUND became 
The One True Way.  With COMPOUND you might have actually
executed some ops before you get to this one so ignoring the
request doesn't seem like a good thing to do.  I don't see 
anything that you can do except return an error.

I think that returning an error would not hurt the mechanism.
If the client is handling the sequencing conservatively, then he
won't be issuing sequence N+1 until a response is obtained
from sequence N, then a server will get something too low
only if a router held and then disgorged an old packet.  In that
case, an error return would be ignored by the client (who
already got a response) and so the situation would be the
same for the client.  If the client were broken and sending
bad sequence numbers, then an error is probably better
as a way to find the problem, anyway.

Another case (I'm not sure if this is legal) is if the client is
more aggressive and decides to send N+1 before he gets the 
response for N, depending on the transport either not to 
re-order or to do so so infrequently that the server's checking 
of sequence numebrs to ensure correct ordering is available
as a little-used backstop.  In that case, if N and N+1 were
transposed in flight, ignoring N+1 and allowing RPC retry
to take care of this is a bit simpler for the client, but it
should be fairly easy for him to deal with a specific sequence 
error by reissuing N+1 (after stripping off any ops in the
COMPOUND) that were actually executed.

In any case, I don't see how we could ignore requests 
without some fairly stringent restrictions on COMPOUND
so I would argue that we have to give back an error here.