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

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 2 Sep 1999 10:46:03 -0700

> > By the way what error should be returned if the handle length
> > is longer than allowed by the protocol?
> 
> That is an RPC level error because it is something that gets 
> detected in the
> XDR decoding phase. The RPOC respond thus has MSG_ACCEPTED, 
> followed by a
> status of GARBAGA_ARGS. It does mean the client loses results of any
> previously xecuted operations, but the client asked for it.
 
Maybe, but just telling him that something somewhere is wrong
in a large COMPOUND seems like Cruel and Unusual Punishment
to me (maybe it's not all that unusual).  The guy who is 
debugging the code when in response to some wierd condition
it generates something invalid may not be the guy who wrote
the code.  Or it may be corrupted by the network stack or a
router along the way.  I think getting it down to the op 
that's screwed up would sure help the poor guy debugging 
the problem.

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.

I wonder how far the concept of XDR decoding errors extends.
Besides exceeding a length specification, how about:

    Wrong value in a descriminated union.  We were just 
    discussing this for illegal op numbers.  If this is 
    an XDR decoding error, then shouldn't an invalid op 
    number (on this account of things) also return "The 
    whole request is screwed up.  You figure it out"?

    Running past the end of the message within an op.

    Values outside an enum.  Boolean values that aren't
    zero or one.  I was assuming that this stuff would
    return INVAL on the op in question just as it would
    if the mask parameter to ACCESS has an invalid 
    mask bit.

I think for all of this stuff the server should return 
something that isolates the problem to the op in question.
If a server can't do that, the client can live with it
since this doesn't happen very often but there is no 
point in throwing away information that you can return
to the client to help him debug.

---

From: Mike Eisler <[email-masked]>
Date: Thu, 2 Sep 1999 11:12:50 -0700 (PDT)

> to me (maybe it's not all that unusual).  The guy who is 

we are punishing bad programmers not human beings. :-)

in any case it is a legal thing to do.

i haven't heard of a v3 client sending > 64 byte fhs, or a v2 client sending >
8192 byte writes. the rpc decode errors are an excellent incentive to conform.

> executing anything?  Presumably not.  [...]

depends on how long the requests are.

>     whole request is screwed up.  You figure it out"?

good point ... the ILLEGAL pseudo op i proposed is thus unnecessary, because
the xdr decode will fail.

> to the client to help him debug.

i've no problem with adding new error codes and tricks like ILLEGAL to do so,
but given that these conditions don't happen that often, my inclination as an
implementor is to not implement any it. rpc decode errors are adequate.

as things stand now, a large chunk of my client and server code is  produced
by rpcgen, and likely will continue to do so until iesg orders publication of
an rfc.

	-mre

---

From: Dickon Hood <[email-masked]>
Date: Fri, 03 Sep 1999 20:14:00 +0100

In message <[email-masked]>
          Mike Eisler <[email-masked]> wrote:

: > > > By the way what error should be returned if the handle length is
: > > > longer than allowed by the protocol?

: > > That is an RPC level error because it is something that gets  detected
: > > in the XDR decoding phase. The RPOC respond thus has MSG_ACCEPTED, 
: > > followed by a status of GARBAGA_ARGS. It does mean the client loses
: > > results of any previously xecuted operations, but the client asked for
: > > it.

Surely there won't've been any previous operations as they'll not have been
decoded yet?

: > Maybe, but just telling him that something somewhere is wrong in a large
: > COMPOUND seems like Cruel and Unusual Punishment to me (maybe it's not
: > all that unusual).  The guy who is 

: we are punishing bad programmers not human beings. :-)

Tsk :-)

: in any case it is a legal thing to do.

: i haven't heard of a v3 client sending > 64 byte fhs, or a v2 client sending >
: 8192 byte writes. the rpc decode errors are an excellent incentive to conform.

I have.  My client (oops) once or twice nuked various linux machines if you
asked it to read or write (I forget which) packets > 8K.  This was some years
ago now though, and the bug has been fixed.

Assuming GARBAGE_ARGS *is* the correct error, and a server doesn't realise
this until it's too late, what is it to do?  Undo operations it has managed
until that point (how?), or what?

: > debugging the code when in response to some wierd condition it generates
: > something invalid may not be the guy who wrote the code.  Or it may be
: > corrupted by the network stack or a router along the way.  I think
: > getting it down to the op  that's screwed up would sure help the poor guy
: > debugging  the problem.

: > Are servers really going to implement a separate XDR decoding phase
: > (involving a probable copy of the entire request), before executing
: > anything?  Presumably not.  [...]

: depends on how long the requests are.

Baring in mind Sun's example RPC code (as shipped with rpcgen from
playground.sun.com) does this, I would imagine quite a lot will.  Some won't,
and I suspect mine will be one.

[...]

: > I think for all of this stuff the server should return  something that
: > isolates the problem to the op in question. If a server can't do that,
: > the client can live with it since this doesn't happen very often but
: > there is no  point in throwing away information that you can return to
: > the client to help him debug.

: i've no problem with adding new error codes and tricks like ILLEGAL to do
: so, but given that these conditions don't happen that often, my inclination
: as an implementor is to not implement any it. rpc decode errors are
: adequate.

I think I agree.  Examining the raw packet dumps of an RPC request isn't that
hard; OK, COMPOUND requests are going to be somewhat larger, but even so. 
The fact that most fields have a length field makes things quite a lot
easier; simple enough that a human can work its way through them with a
little effort.

-- 
Dickon Hood

Due to binaries posted to non-binary newsgroups, my .sig is 
temporarily unavailable.  Normal service will be resumed as soon as
possible.  We apologise for the inconvenience in the mean time.

---

From: Mike Eisler <[email-masked]>
Date: Sat, 4 Sep 1999 10:11:45 -0700 (PDT)

> Surely there won't've been any previous operations as they'll not have been

unless the COMPOUND isn't being used for doing an operation on
different files:

	putfh fh1 ; read ; putfh2 fh2 (with bad length) read.

> : i haven't heard of a v3 client sending > 64 byte fhs, or a v2 client
> sending > : 8192 byte writes. the rpc decode errors are an excellent
> incentive to conform.
> 

Which is my point. I'd never heard of your client doing it. You fixed it,
probably quite quickly.
 
> until that point (how?), or what?

If the server decodes the entire request first, there are no operations to
undo.

If it is decoding on the fly, then undo'ing operations is in general
impractical. (e.g how do you undo an REMOVE? Sure it can be done but that's an
awful lot of engineering just because there are a few broken clients that
didn't didn't use rpcgen to produce their first cut of xdr code).

The server could either return GARBAGEARGS, thus giving the client no
indication that part of the request succeeded, or we had per op error codes to
deal with XDR decoding problems.

I think the former is sufficient, but don't object if someone wants to 
propose options for implementing the latter. In any case, a server that
returns GARBAGEARGS is doing the correct thing.

	-mre