Changes between Initial Version and Version 11 of Ticket #16

2007-08-20T20:45:10Z (15 years ago)

in chatting with zooko, I've decided to add this to the list of stuff to do for 0.6, because the non-uniformity problem is important in my mind. Beyond 0.6, we probably need to sit down and work on DEN, because both TahoeTwo and TahoeThree require a fully-connected mesh, and I'd be leery of using that beyond a few hundred nodes.


  • Ticket #16

    • Property Status changed from new to assigned
    • Property Component changed from component1 to code-peerselection
    • Property Summary changed from explain/justify our current Peer Selection to move to Tahoe2 peer selection algorithm
    • Property Priority changed from minor to major
    • Property Version changed from to 0.5.0
    • Property Milestone changed from to 0.6.0
    • Property Owner changed from zooko to warner
  • Ticket #16 – Description

    initial v11  
    1 also, if you get a chance, could you try and remember why we went with the 'Tahoe3' peer selection algorithm instead of the 'Tahoe2' first-100-peers-in-the-permuted-list approach? and maybe add it to the wiki under PeerSelection or I think there's a PeerSelection/TahoeThree page waiting to be created?
    2 I wasn't able to remember our reasons when I wrote up the arch doc
     1Implement the TahoeTwo peer-selection algorithm for share upload. This is the
     2first-N-peers-in-the-permuted-list approach, as opposed to the TahoeThree
     3"shares in baskets" scheme that's present in 0.5.0. TahoeThree can result
     4severe non-uniform distribution of shares (in some cases, all shares being
     5given to the same node), which hurts reliability, and is worse in small
     8The share download is still ask-everybody, which will work up to maybe 100
     9peers. Eventually we'll move that to TahoeTwo as well.
     11In the longer run, we'll need to move to DenverAirport, to get beyond a few
     12hundred peers, but we're thinking post-0.6.0 for that.