2006-12-01 00:16:19 +00:00
|
|
|
|
2006-12-04 02:55:05 +00:00
|
|
|
['*' means complete]
|
|
|
|
|
2007-04-03 17:16:20 +00:00
|
|
|
Connection Management:
|
2007-04-30 16:57:52 +00:00
|
|
|
*v1: foolscap, no relay, live=connected-to-introducer, broadcast updates, fully connected topology
|
2007-05-02 03:33:22 +00:00
|
|
|
v2: configurable IP address -- http://allmydata.org/trac/tahoe/ticket/22
|
|
|
|
v3: live != connected-to-introducer, connect on demand
|
|
|
|
v4: relay?
|
2006-12-01 00:16:19 +00:00
|
|
|
|
2007-04-03 17:16:20 +00:00
|
|
|
File Encoding:
|
2007-01-19 09:17:24 +00:00
|
|
|
*v1: single-segment, no merkle trees
|
2007-04-03 17:14:34 +00:00
|
|
|
*v2: multiple-segment (LFE)
|
2007-04-19 17:44:37 +00:00
|
|
|
*v3: merkle tree to verify each share
|
|
|
|
*v4: merkle tree to verify each segment
|
|
|
|
v5: only retrieve the minimal number of hashes instead of all of them
|
2006-12-01 00:16:19 +00:00
|
|
|
|
2007-04-03 17:16:20 +00:00
|
|
|
Share Encoding:
|
2007-01-19 09:17:24 +00:00
|
|
|
*v1: fake it (replication)
|
|
|
|
*v2: PyRS
|
2007-03-28 07:05:16 +00:00
|
|
|
*v2.5: ICodec-based codecs, but still using replication
|
|
|
|
*v3: C-based Reed-Solomon
|
2007-01-19 09:17:24 +00:00
|
|
|
|
2007-04-05 19:34:22 +00:00
|
|
|
URI:
|
|
|
|
*v1: really big
|
|
|
|
v2: derive more information from version and filesize, to remove codec_name,
|
|
|
|
codec_params, tail_codec_params, needed_shares, total_shares, segment_size
|
|
|
|
|
|
|
|
Upload Peer Selection:
|
2006-12-04 02:51:33 +00:00
|
|
|
*v1: permuted peer list, consistent hash
|
2007-04-05 19:34:22 +00:00
|
|
|
*v2: permute peers by verifierid and arrange around ring, intermixed with
|
|
|
|
shareids on the same range, each share goes to the
|
|
|
|
next-clockwise-available peer
|
|
|
|
v3: reliability/goodness-point counting?
|
|
|
|
v4: denver airport (chord)?
|
|
|
|
|
|
|
|
Download Peer Selection:
|
|
|
|
*v1: ask all peers
|
|
|
|
v2: permute peers and shareids as in upload, ask next-clockwise peers first
|
|
|
|
(the "A" list), if necessary ask the ones after them, etc.
|
|
|
|
v3: denver airport?
|
2006-12-01 00:16:19 +00:00
|
|
|
|
2007-04-03 17:32:34 +00:00
|
|
|
Filetable Maintenance:
|
2007-04-30 16:57:52 +00:00
|
|
|
*v1: vdrive-based tree of MutableDirectoryNodes, persisted to vdrive's disk
|
2006-12-04 11:43:33 +00:00
|
|
|
no accounts
|
|
|
|
v2: move tree to client side, serialize to a file, upload,
|
2007-04-30 16:57:52 +00:00
|
|
|
vdrive.set_filetable_uri (still no accounts, just one global tree)
|
2006-12-04 11:43:33 +00:00
|
|
|
v3: break world up into accounts, separate mutable spaces. Maybe
|
|
|
|
implement SSKs
|
2007-01-19 09:17:24 +00:00
|
|
|
v4: filetree
|
2006-12-01 00:16:19 +00:00
|
|
|
|
2007-04-03 17:32:34 +00:00
|
|
|
Checker/Repairer:
|
2006-12-04 11:43:33 +00:00
|
|
|
*v1: none
|
2006-12-01 00:16:19 +00:00
|
|
|
v2: centralized checker, repair agent
|
|
|
|
v3: nodes also check their own files
|
|
|
|
|
2007-04-03 17:32:34 +00:00
|
|
|
Storage:
|
2007-04-19 17:44:37 +00:00
|
|
|
*v1: no deletion, one directory per verifierid, no owners of shares,
|
2006-12-01 00:16:19 +00:00
|
|
|
leases never expire
|
2007-04-03 17:16:44 +00:00
|
|
|
*v2: multiple shares per verifierid [zooko]
|
2007-04-05 19:34:22 +00:00
|
|
|
v3: deletion
|
|
|
|
v4: leases expire, delete expired data on demand, multiple owners per share
|
2006-12-01 00:16:19 +00:00
|
|
|
|
2007-04-03 17:16:20 +00:00
|
|
|
UI:
|
2006-12-04 11:43:33 +00:00
|
|
|
*v1: readonly webish (nevow, URLs are filepaths)
|
2006-12-05 02:56:22 +00:00
|
|
|
*v2: read/write webish, mkdir, del (files)
|
|
|
|
v2.5: del (directories)
|
2007-04-05 19:34:22 +00:00
|
|
|
v3: PB+CLI tool.
|
|
|
|
v3.5: XUIL?
|
2006-12-04 11:43:33 +00:00
|
|
|
v4: FUSE
|
2006-12-01 00:16:19 +00:00
|
|
|
|
2007-04-10 17:33:38 +00:00
|
|
|
Operations/Deployment/Doc/Free Software/Community:
|
2007-04-30 16:57:52 +00:00
|
|
|
- move this file into the wiki ?
|
2007-04-03 17:32:47 +00:00
|
|
|
|
2006-12-01 00:16:19 +00:00
|
|
|
back pocket ideas:
|
|
|
|
when nodes are unable to reach storage servers, make a note of it, inform
|
2007-04-30 16:57:52 +00:00
|
|
|
verifier/checker eventually. verifier/checker then puts server under
|
|
|
|
observation or otherwise looks for differences between their self-reported
|
|
|
|
availability and the experiences of others
|
2006-12-01 00:16:19 +00:00
|
|
|
|
2006-12-02 02:17:50 +00:00
|
|
|
store filetable URI in the first 10 peers that appear after your own nodeid
|
|
|
|
each entry has a sequence number, maybe a timestamp
|
|
|
|
on recovery, find the newest
|
|
|
|
|
2006-12-04 08:25:12 +00:00
|
|
|
multiple categories of leases:
|
2007-04-05 19:34:22 +00:00
|
|
|
1: committed leases -- we will not delete these in any case, but will instead
|
|
|
|
tell an uploader that we are full
|
|
|
|
1a: active leases
|
|
|
|
1b: in-progress leases (partially filled, not closed, pb connection is
|
|
|
|
currently open)
|
|
|
|
2: uncommitted leases -- we will delete these in order to make room for new
|
|
|
|
lease requests
|
|
|
|
2a: interrupted leases (partially filled, not closed, pb connection is
|
|
|
|
currently not open, but they might come back)
|
|
|
|
2b: expired leases
|
|
|
|
|
|
|
|
(I'm not sure about the precedence of these last two. Probably deleting
|
|
|
|
expired leases instead of deleting interrupted leases would be okay.)
|
2006-12-04 02:55:05 +00:00
|
|
|
|
2006-12-01 00:16:19 +00:00
|
|
|
big questions:
|
|
|
|
convergence?
|
2006-12-02 02:17:50 +00:00
|
|
|
peer list maintenance: lots of entries
|
2006-12-04 02:55:05 +00:00
|
|
|
|