Changes between Initial Version and Version 1 of Ticket #5


Ignore:
Timestamp:
2007-04-27T03:24:21Z (17 years ago)
Author:
warner
Comment:

fix some wikinames

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #5 – Description

    initial v1  
    1818So I'm thinking that the share index needs to be verifierid plus a serialized representation of the encoding parameters. The serialized parameters can be compressed by just saying "v1" and havin that imply a certain algorithm applied to the filesize, but that should still give us the ability to change encoding parameters in the future and not wind up with incompatible shares that appear identical from the perspective of get_buckets().
    1919
    20 There is certain information that needs to go into peer selection (depending upon the algorithm).  The verifierid is one of them, the number of shares that were uploaded is another (at least for PeerSelection/Tahoe3 and PeerSelection/DenverAirport .. PeerSelection/Tahoe2 does not need it). There is some information that can affect the shares being generated without influencing peer selection (like segment size): this data could be stored on the peers and retrieved at download time. Peers could store shares from multiple encoded forms of the same crypttext. The download process would involve the downloader asking a set of likely peers about a verifierid, and learning of a set of encoded forms, such that the peer has buckets for some forms and not others. The response that provides a list of encoded forms includes the encoding parameters, so the downloader could learn about how many buckets for that form it needs to recover the file. The second step would be to pick one form and retrieve references to sufficient buckets for that form, then finally the data could be fetched and decoded.
     20There is certain information that needs to go into peer selection (depending upon the algorithm).  The verifierid is one of them, the number of shares that were uploaded is another (at least for PeerSelection/TahoeThree and PeerSelection/DenverAirport .. PeerSelection/TahoeTwo does not need it). There is some information that can affect the shares being generated without influencing peer selection (like segment size): this data could be stored on the peers and retrieved at download time. Peers could store shares from multiple encoded forms of the same crypttext. The download process would involve the downloader asking a set of likely peers about a verifierid, and learning of a set of encoded forms, such that the peer has buckets for some forms and not others. The response that provides a list of encoded forms includes the encoding parameters, so the downloader could learn about how many buckets for that form it needs to recover the file. The second step would be to pick one form and retrieve references to sufficient buckets for that form, then finally the data could be fetched and decoded.
    2121