[AFS3-std] Re: abort packet format

[Derrick Brashear]

On Wed, Mar 9, 2011 at 12:44 PM, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
> 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. =A0You 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.

the problem is when you're being throttled, the *real error* is
delayed. do you throw away the real
error, or do you provide a second, unsolicited reply?

> 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?

i had intended a human-readable message which happened to be a fixed
string for each case, and a receiver would be expected to translate it
to the
appropriate locality. but i am not wed to this implementation of it.



--=20
Derrick