* Matthew Toseland <toad at amphibian.dyndns.org> [2009-03-10 23:16:18]:
> 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. > If you do so you can't even tell which is a fast and which is a slow node! -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090311/e72cd984/attachment.pgp>
