[tahoe-dev] protocol versioning (v2, as it were)

[Brian Warner]

> Excellent write-up of the versioning plan. One question I have was: what's
> that part about corrupting files?

I was probably thinking about #439 "don't write corrupt >12GiB files"

This bug was a missing assertion on the storage-server side. Files larger
than about 12GiB would have share sizes that would overflow the 4-byte field
we reserved for it. I added the assertion in revision [2620] (06-Jun-2008),
tahoe-1.0.0 was missing the assertion and tahoe-1.1.0 contained the
assertion.

My claim was that a 1.2.0-or-older client could experience corruption in
>12GiB files, because they have no way to tell that the server is newer than
1.0.0 or not. A 1.3.0-or-newer client will do get_version(), and will refuse
to use the server for large files unless it claims support for large shares,
and thus will not experience corruption.

That 1.3.0-or-newer client, when it sends get_version() to a 1.2.0-or-older
server, will get a NameError or Violation, and it won't be able to
distinguish between a 1.0.0 server, a 1.1.0 server, and a 1.2.0 server. But
the "default version dictionary" that it uses in all of these cases includes
a max-immutable-share-size of 2**32, meaning that 1.3.0-or-newer client won't
try to send large shares to it, so there's no chance of corruption.

I'm not sure it's worth the effort, but we could expand on issue #3 with a
two-dimensional table:

 client = 1.3.0-or-newer
  server = 1.4.0-or-newer (with large shares) : no corruption, large files ok
  server = 1.3.0 : no corruption, large files rejected (by client)
  server = 1.2.0 : no corruption, large files rejected (by client)
  server = 1.1.0 : no corruption, large files rejected (by client)
  server = 1.0.0 : no corruption, large files rejected (by client)

 client = 1.2.0-or-older
  server = 1.4.0-or-newer (with large shares) : no corruption, large files ok
  server = 1.3.0 : no corruption, large files rejected (by server)
  server = 1.2.0 : no corruption, large files rejected (by server)
  server = 1.1.0 : no corruption, large files rejected (by server)
  server = 1.0.0 : large files corrupted, small files ok


> I don't see how v1.2.0 clients could get corruption though -- current and
> future storage servers will give a clean error if they can't handle the
> size of file being uploaded.

Yeah, but old storage servers didn't give that error. It's only the client =
1.2.0-or-older and server = 1.0.0-or-older case that allows corruption.

cheers,
 -Brian