Subject: RE: Questions about FH ops (GETFH, SAVEFH, PUTFH, RESTOREFH)

From: Brent Callaghan <[email-masked]>
Date: Thu, 2 Sep 1999 11:15:54 -0700 (PDT)

Dave Noveck writes:
> Are servers really going to implement a separate XDR decoding
> phase (involving a probable copy of the entire request), before
> executing anything?  Presumably not.  Decoding of ops is going
> to be interleaved with execution to some degree, at least it
> will be in most servers.  There should be a way to reflect that
> so that request structuring errors can be meaningfully returned.

Good point.

The RPC GARBAGE_ARGS error is fine for conventional
RPC protocols where the arguments were just arguments
and nothing more.  However, in the case of COMPOUND
it seems a bit inadequate.

If your server is using XDR routines generated directly
from rpcgen, then you've got no easy alternatives.
The request has to be XDRed into a massive union
in a first pass - then the semantics are handled in
a second pass - through the union.  If the first
pass cannot be completed because of an XDR error,
the server has to return GARBAGE_ARGS.

However, I'm doing the v4 client/server in Java, and there the
situation is quite different.  Rather than do the
two-pass thing, it's much easier to handle the
request in a single pass - XDRing ops as you need
them.  For instance, a linked list XDRs decodes like this:

	while (xdr_bool()) {
		:
	}

My single-pass XDR server may have executed some of the ops 
in a COMPOUND before it discovers one with bad args.
Hence, a simple RPC GARBAGE_ARGS reply is inadequate
since the client may need to know just what was done
and what wasn't.

So, for those of us who XDR on the fly, I support
Dave in his request for an NFS error that covers
bad arguments, e.g.

	NFS4ERR_BADARGS		An error occurred in the XDR
				decoding of the arguments to
				the operation.

		Brent