[tahoe-dev] [tahoe-lafs] #778: "shares of happiness" is the wrong measure; "servers of happiness" is better

[tahoe-lafs]

#778: "shares of happiness" is the wrong measure; "servers of happiness" is
better
---------------------------------------+------------------------------------
 Reporter:  zooko                      |           Owner:  warner
     Type:  defect                     |          Status:  new   
 Priority:  critical                   |       Milestone:  1.6.0 
Component:  code-peerselection         |         Version:  1.4.1 
 Keywords:  reliability review-needed  |   Launchpad_bug:        
---------------------------------------+------------------------------------

Comment(by kevan):

 Replying to [comment:148 zooko]:
 > Yeah, there are two notions of "complexity". One is computational --
 basically "the size of the code for the shortest implementation of this".
 The other is cognitive -- basically "the difficulty for the Tahoe-LAFS
 hackers to learn this and then to hold it correctly in their heads".
 >
 > It ''might'' be the case that making both data structures be maps from
 shareid to set of serverid would make the algorithm "simpler" in the
 latter way -- easier to comprehend. I'm not sure.

 I thought about it more, and found a lot to like about this idea. Not only
 did it eliminate {{{should_add_server}}}, but it made
 {{{servers_of_happiness}}} (to me, at least) much clearer. I implemented
 that earlier today, and I'll attach updated patches with that shortly.
 Please read {{{servers_of_happiness}}} (now at
 src/allmydata/util/happinessutil.py, since there was no good reason not to
 calculate happiness the same way in the encoder as we do in the peer
 selection process) again, and if it is still confusing, hopefully we can
 fix it so that it isn't.

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/778#comment:149>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid