]> git.rkrishnan.org Git - tahoe-lafs/tahoe-lafs.git/commit
immutable: refactor downloader to be more reusable for checker/verifier/repairer...
authorZooko O'Whielacronx <zooko@zooko.com>
Mon, 5 Jan 2009 16:51:45 +0000 (09:51 -0700)
committerZooko O'Whielacronx <zooko@zooko.com>
Mon, 5 Jan 2009 16:51:45 +0000 (09:51 -0700)
commit778167c2b1926063149e27edc08b4df5e83f4d2a
tree34508d516583192d7fefa418ab9b61d4e6376f4f
parent5d5e89d96d7a78d28399d955e28eabee36ed28d6
immutable: refactor downloader to be more reusable for checker/verifier/repairer (and better)

The code for validating the share hash tree and the block hash tree has been rewritten to make sure it handles all cases, to share metadata about the file (such as the share hash tree, block hash trees, and UEB) among different share downloads, and not to require hashes to be stored on the server unnecessarily, such as the roots of the block hash trees (not needed since they are also the leaves of the share hash tree), and the root of the share hash tree (not needed since it is also included in the UEB).  It also passes the latest tests including handling corrupted shares well.

ValidatedReadBucketProxy takes a share_hash_tree argument to its constructor, which is a reference to a share hash tree shared by all ValidatedReadBucketProxies for that immutable file download.

ValidatedReadBucketProxy requires the block_size and share_size to be provided in its constructor, and it then uses those to compute the offsets and lengths of blocks when it needs them, instead of reading those values out of the share.  The user of ValidatedReadBucketProxy therefore has to have first used a ValidatedExtendedURIProxy to compute those two values from the validated contents of the URI.  This is pleasingly simplifies safety analysis: the client knows which span of bytes corresponds to a given block from the validated URI data, rather than from the unvalidated data stored on the storage server.  It also simplifies unit testing of verifier/repairer, because now it doesn't care about the contents of the "share size" and "block size" fields in the share.  It does not relieve the need for share data v2 layout, because we still need to store and retrieve the offsets of the fields which come after the share data, therefore we still need to use share data v2 with its 8-byte fields if we want to store share data larger than about 2^32.

Specify which subset of the block hashes and share hashes you need while downloading a particular share.  In the future this will hopefully be used to fetch only a subset, for network efficiency, but currently all of them are fetched, regardless of which subset you specify.

ReadBucketProxy hides the question of whether it has "started" or not (sent a request to the server to get metadata) from its user.

Download is optimized to do as few roundtrips and as few requests as possible, hopefully speeding up download a bit.
src/allmydata/immutable/download.py
src/allmydata/immutable/encode.py
src/allmydata/immutable/layout.py
src/allmydata/interfaces.py
src/allmydata/offloaded.py
src/allmydata/scripts/debug.py
src/allmydata/test/test_encode.py
src/allmydata/test/test_hashtree.py
src/allmydata/test/test_immutable.py
src/allmydata/test/test_storage.py