On Wed, Mar 9, 2011 at 12:44 PM, Jeffrey Hutzelman <[email protected]> wrote: > On Tue, 2011-03-08 at 22:04 -0600, Andrew Deason wrote: >> On Tue, 08 Mar 2011 20:48:55 -0500 >> Jason Edgecombe <[email protected]> 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.
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. -- Derrick _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
