tahoe-lafs/trac-2024-07-25

allow introducer to provide default encoding parameters (k-of-n) #84

New issue

Closed

opened 2007-07-12 18:21:19 +00:00 by warner · 4 comments

warner commented

2007-07-12 18:21:19 +00:00

Owner

For small+centrally-managed grids, the admin of the introducer should be able to recommend the values for k and n (as in k-of-n encoding). The value of 'n' should be set to be about the maximum number of peers in the network, since there's no point in producing more shares than there are peers (unless you expect more peers to arrive in the future, and we need to write more code to take advantage of new peers without reencoding anyways). The value of 'k' should be set to achieve whatever reliability-vs-expansion goals you have in mind.

For small networks, we're thinking that 3-of-10 seems like a good idea.

tahoe-lafs added the

labels 2007-07-12 18:21:19 +00:00

tahoe-lafs added this to the 0.5.0 milestone 2007-07-12 18:21:19 +00:00

warner commented

2007-07-12 23:30:11 +00:00

Author

Owner

Done. Write to a file named 'encoding_parameters' in the introducer's base directory, with three numbers in it (like "3 7 10", or "3\n7\n10\n"), and they will be used as (k, desired, n), where 'desired' is the threshold that the uploader will be happy with (it will try to place all 'n' shares, but up to n-desired shareholders can drop out during upload without triggering a failure).

And note that setting k=1 is equivalent to replication.

tahoe-lafs added the

fixed

label 2007-07-12 23:30:11 +00:00

warner closed this issue

2007-07-12 23:30:11 +00:00

daira commented

2013-04-10 23:20:35 +00:00

Author

Owner

I wasn't aware this had been fixed. Was it fixed and then undone, or only partly implemented?

tahoe-lafs removed the

fixed

label 2013-04-10 23:20:35 +00:00

daira reopened this issue

2013-04-10 23:20:35 +00:00

warner commented

2013-04-11 11:42:45 +00:00

Author

Owner

I think it was implemented, then we decided it wasn't such a good idea after all and disabled it. There's some vestigal support RIIntroducerSubscriberClient_v2.set_encoding_parameters, but it doesn't end up doing anything (I think it sets introducer_client.encoding_parameters which is then ignored).

It might be worth talking about whether we should bring it back (I think I made the argument that the introducer is in a slightly better position to know good parameters, and I think Zooko made the argument that clients should be making that decision for themselves). It might also be worth talking about systematically removing the lingering code (except maybe for the actual remote method receiver, which should stick around as a NOP so that old introducers who try to call it won't cause exceptions).

I'll mark this as reclosed.

I think it was implemented, then we decided it wasn't such a good idea after all and disabled it. There's some vestigal support `RIIntroducerSubscriberClient_v2.set_encoding_parameters`, but it doesn't end up doing anything (I think it sets `introducer_client.encoding_parameters` which is then ignored). It might be worth talking about whether we should bring it back (I think I made the argument that the introducer is in a slightly better position to know good parameters, and I think Zooko made the argument that clients should be making that decision for themselves). It might also be worth talking about systematically removing the lingering code (except maybe for the actual remote method receiver, which should stick around as a NOP so that old introducers who try to call it won't cause exceptions). I'll mark this as reclosed.

tahoe-lafs added the

fixed

label 2013-04-11 11:42:45 +00:00

warner closed this issue

2013-04-11 11:42:45 +00:00

warner commented

2016-04-02 20:17:08 +00:00

Author

Owner

The vestigal support got removed in the 1.11.0 release, by [56a9f5ad].