what happens if you run out of sequence numbers in mutable files

[zooko]

One of the reviewers for our paper for StorageSS08 questioned what happens if the mutable file sequence number gets maxed out, for example by a naughty client setting it to max.

We had earlier discussed making the space of sequence numbers for mutable files be a ring, so that comparison of two sequence numbers is actually "which of these two numbers is closest to the other in the clockwise direction".

We would have to establish some tie-breaking rule in the case that they are equidistant, and we would have to spend a few brain cycles thinking about what happens when there are more than two sequence numbers extant for a given file.

Most likely weird cases like max sequence number or equidistance sequence numbers can arise only if a client is confused or misbehaving. (Or, I suppose if a client has written or attempted to write 2⁶⁴ successive versions of a file.) Since a client can't effect the sequence number without write authority, and since a client with write authority can also simply overwrite the file with garbage over and over, it isn't clear that being able to mess with the sequence number gives any worse power to a naughty client than it already has.

So the goal should just be to define a semantics for sequence numbers which is simple enough that implementors and users won't write code which gets confused and does something bad when faced with the edge cases. Assuming that someone is going to write some code which reads and writes these sequence numbers, or relies on Tahoe's reading and writing of these sequence numbers, we don't want that code to be susceptible to some surprising failure mode if the sequence numbers exhibit unusual behavior.

[davidsarah]

Tagging issues relevant to new cap protocol design.