--On Wednesday, October 14, 2009 05:50:17 PM -0400 Marcus Watts
<[email protected]> wrote:
So, for instance, if the client is in the middle of a bulk data write,
and the server decides to return "VICETOKENDEAD", then on the client
there is a problem. The client has no way to know how much of the
write was accepted by the server before the error was returned
Sure it does. RPC's are atomic. If the RPC failed, it failed, period.
The server is responsible for ensuring that it has not committed any change
(note that in practice, OpenAFS doesn't actually do this, which means it is
already possible for things to break).
Note that any of the failure modes you describe can happen today with an
expired token.
2/
For key version numbers, wraparound should not be a real problem.
You don't need to send the whole version number, you only need to send
the least significant bits - enough to distinguish between "old" and
"new". Of course you still need to store the whole thing at both ends
That depends on whether key version numbers are just versions, or actual
counters used to produce a derived key. If the former, you don't need to
store the whole thing anywhere; you'll only have a few relevant ones at a
time, and it's well-understood how to handle operations on mod-n sequence
number spaces.
On the wire, one bit is probably sufficient
Nope. If the current key is represented by value 0, does 1 mean the next
key or the last one? You need a few bits, depending on how many keys might
be relevant. Again, this sort of sequence number is fairly well
understood; see TCP.
-- Jeff
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
