tahoe-lafs/roadmap.txt

103 lines
3.2 KiB
Plaintext
Raw Normal View History

2006-12-01 00:16:19 +00:00
2006-12-04 02:55:05 +00:00
['*' means complete]
Connection Management:
*v1: foolscap, no relay, live=connected-to-queen, broadcast updates, full mesh
2006-12-01 00:16:19 +00:00
v2: live != connected-to-queen, connect on demand
v3: relay?
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)
2006-12-01 00:16:19 +00:00
v3: merkle tree to verify each share
v4: merkle tree to verify each segment
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
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
*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:
2006-12-04 11:43:33 +00:00
*v1: queen-based tree of MutableDirectoryNodes, persisted to queen's disk
no accounts
v2: move tree to client side, serialize to a file, upload,
queen.set_filetable_uri (still no accounts, just one global tree)
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:
2006-12-04 02:51:33 +00:00
*v1: no deletion, one directory per verifierid, one owner per share,
2006-12-01 00:16:19 +00:00
leases never expire
*v2: multiple shares per verifierid [zooko]
v3: deletion
v4: leases expire, delete expired data on demand, multiple owners per share
2006-12-01 00:16:19 +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)
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
Operations/Deployment:
v1: doc how to set up a network (introducer, vdrive server, nodes)
v2: Windows port and testing
v3: Trac instance
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
queen eventually. queen then puts server under observation or otherwise
looks for differences between their self-reported availability and the
experiences of others
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
multiple categories of leases:
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?
peer list maintenance: lots of entries
2006-12-04 02:55:05 +00:00