[OpenAFS-devel] Discarding tokens -- is this good?

[Robert Banz]

On Nov 12, 2006, at 10:48 AM, Jeffrey Altman wrote:

> Robert Banz wrote:
>>             if ((acode == VICETOKENDEAD) || (acode == RXKADEXPIRED))
>>
>> Leads to the same message, I've added an extra bit to the  
>> "...expired"
>> error message to tell me *which* of these is the case -- but I'm  
>> pretty
>> sure that from the client's perspective it's tokens shouldn't be
>> expiring for quite awhile.
>
> VICETOKENDEAD does not mean that the client's tokens are expired.
> It means that the token's associated with the RX connection are  
> expired.
> The file server sends this error when the last call received by the
> file server was so long ago that the tokens associated with the
> connection are no longer good.  Its meant to trigger the use of a new
> RX connection.  It should not trigger the destruction of the tokens
> held by the client.
>
> Only an RXKADEXPIRED or RXKADBADTICKET should do that.

Thanks for the better explanation of the error codes.

According to the code in the client, all three of these states lead  
to the same result -- getting UTokensBad set in user->states, with  
the only difference in handling being that VICETOKENDEAD &  
RXKADEXPIRED printing the "...expired" error message, and  any other  
RXK error gets it's error code printed.  Check out afs/afs_analyze.c...

The intended behavior that you describe above makes sense, however,  
the current way the error handling is coded doesn't follow.  My only  
"fear" in fixing this a lack of understanding of some of the  
ramifications.  While it looks relatively simple to ask for a retry  
of the call, and initiate a new RX connection, there doesn't seem to  
currently be a way to put a limit on how many times something would  
be retried.  I think that would require adding a counter to vrequest  
to track how many times this request may have been retried as I don't  
think it should be unbounded -- at some point it should end up  
throwing an IO error back up the stack...  Or are there already  
limits in-place for this?

Thoughts?