On Monday 02 March 2009 20:55:59 Florent Daigni?re wrote: > * Evan Daniel <evanbd at gmail.com> [2009-03-02 15:41:59]: > > > On Mon, Mar 2, 2009 at 3:11 PM, Florent Daigni?re > > <nextgens at freenetproject.org> wrote: > > > * Evan Daniel <evanbd at gmail.com> [2009-02-27 10:58:19]: > > >> I think it would be inappropriate to reduce the connection limit > > >> without further testing. > > [...] > > > Tweaking that code based on one's experience is just plain silly. > > > > Then it seems we're in agreement. > > > > Tweaking an emergent system based on hunches is silly. Gathering data > > and tweaking based on that data isn't. Individual anecdotes like my > > node's performance prove nothing, but can suggest routes for further > > investigation. Right now, all I think we know is that the current > > system works, and that there is reason to believe improvement is > > possible (ie unused available bandwidth). Do you disagree with that > > assessment? > > > > Is there a reason not to investigate this? I'm not wedded to any > > particular solution or testing method, and I can think of plenty of > > flaws in mine. If you have an improved proposal, by all means say so. > > > > Yes, they are *good* reasons why we should keep the number of peers > constant accross nodes. > > - makes traffic analysis harder (CBR is good; there is even an argument > saying we should pad and send garbage if we have to)
How is this related to the number of peers being constant across very fast and very slow nodes? On a node with a very low transfer limit, we will have different padding behaviour than on a node with a very high transfer limit: a fast node has more opportunities for padding because we have a fixed period of time for coalescing. > - we don't want to go back to the "route and missroute according to load" approach Agreed. > - dynamic systems are often easier to abuse than static ones > > It has been discussed numerous times already; As far as I am concerned, > nothing has changed... We have to accept that we will always have to > deal with slow nodes and those are going to determine the speed of the > whole network. The only parameter we should change is the height of the > "entry fence": how much is the minimal configuration needed to access > freenet. > > Obviously that's some form of elitism... but that's much better than the > alternative (creating a dynamic, fragile system which will work well only > for *some* people). I don't see why it would be more fragile... however we would have to deploy it and try to see if we can tell whether it's an improvement, which may be tricky... > > NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090310/851256a5/attachment.pgp>
