On Wednesday 11 March 2009 19:33:48 Florent Daigni?re wrote: > * 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!
I don't understand. A slow node can be perfectly acceptable and useful provided you only send it as many requests as it can handle. We can do this by reducing the number of nodes connected to it, as well as by accepting fewer requests (which we do now). -------------- 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/20090312/2a095709/attachment.pgp>
