[AFS3-std] Re: abort packet format

[Jeffrey Hutzelman]

On Tue, 2011-03-08 at 22:04 -0600, Andrew Deason wrote:
> On Tue, 08 Mar 2011 20:48:55 -0500
> Jason Edgecombe <jason@rampaginggeek.com> wrote:
> 
> > ok, so is there any unallocated space in the payload? Does adding this
> > require a new RPC or something?
> 
> It's at a lower level than RPCs. But it'll require some standards doc
> and all that, I expect. The payload is variable; I expect we have as
> much space to work with as will fit in a single packet.
> 
> >>> On 03/07/2011 11:28 AM, Derrick Brashear wrote:
> >>>> right now, abort packets have a payload of "the error". anything
> >>>> beyond the 32 bit error in the payload is undefined.
> >>>>
> >>>> comments on exploring a way to ship additional data, like a reason
> >>>> in the event of e.g. delayed abort (so clients can be notified
> >>>> they're being throttled)?
> 
> Well, just make the next 32 bits a "reason" code? While we could try
> bit-packing stuff or something, it's hard to see the rationale without
> having an idea of what we might also want to put in there in the future.
> 
> Or hmm, is a bitfield more appropriate? Allocate a bit for "you're being
> throttled"? We could just say the 33rd bit represents a throttling flag,
> and the next 7 (or 31; but I'm assuming we can include individual bytes)
> must be 0 until we define them to mean something.

Ugh.  You want to permanently allocate a bit in all abort packets to
mean "you're being throttled", even though that bit would have meaning
in combination with one specific error code?

It seems to me the correct way to make "you're being throttled"
something the client can tell is by adding an error code that means
that.


Providing additional information in abort packets seems reasonable, but
let's think carefully about how to do it.

Is the "reason code" you propose simply a sub-error-code, which means
you have a table of possible reasons for every possible error code?
Does it have application- or call-specific meaning?
Is it implementation-dependent?
Is it intended to be something that clients can examine to decide how to
behave, or is it purely to provide additional information to humans?
What about a human-readable message?
And if we do that, what about internationalization?

-- Jeff