* Matthew Toseland <toad at amphibian.dyndns.org> [2008-07-07 12:17:33]:
> 3. Eliminate all checkboxes in the installer, move to the wizard, and > create an advanced options button in the installer. (Toad) > > This would streamline installation significantly: Paranoid users could > click a box to turn UPnP etc on/off, everyone else doesn't need to worry > about it. > Heh, what's the story about the installer and the checkboxes? Good to know that you have debated that... and reached some kind of agreement; I wasn't even aware that those checkboxes were a problem! That said I'm more than happy to hand over the maintainance of the installer :p > 5. THROTTLE EVERYTHING !! (Toad) > > Not all traffic is throttled at the moment. We should subject all > traffic, not only data transfer packets, to both congestion control and > bandwidth limiting. This is related to the low-level streams proposal, > but can be done without it, and should be easier. This is especially > problematic for online gaming. See bug 2312. Note that a lot of Freenet > runs on altruism, thus it is *essential* that it not severely disrupt > a user's internet connection! > I think that this one is important. > 7. Automatic bandwidth limit calibration. (Toad) > > Several other p2p apps implement this, we should too. Bandwidth is *the* > scarce resource most of the time, we want to use as much of it as we can > without significantly slowing down the user's internet connection (see > above). > I don't think that such a thing can reliably work. It might work in 80% of the cases but will badly screw up in others. > TO IMPLEMENT IN 0.9: > > 1. Streams (low level optimisation) > > At the moment, Freenet is quite inefficient in bandwidth usage: the > payload percentage, especially on nodes with low bandwidth limits but > also on nodes with high bandwidth limits, can be quite low, 70%, maybe > 50%... this is unacceptable. A lot of this is due to message padding. If > we split block transfers (and large messages) into streams which can be > sliced up byte-wise however big we want them, rather than into 1K blocks, > then we will need much less padding and so acheive a higher payload > percentage. This also has significant side benefits for steganography and > for connections with low MTU, since we can (on a link with live streams) > construct useful packets of almost any size. > I am not convinced that I understand the logic here... I can't believe you guys plan on implementing (7) without that. In case you didn't suspect it: here is a big news: "available and effective throughput depend on packet sizes amongst other things". At the moment we have oversized packets with a per-link MTU... which is poorly guessed and never adapted. > DATA COLLECTION: > > 1. Push/pull tests. > > We should do push/pull tests regularly on the real network. On darknet this > won't work well because of the difficulty of getting somebody you're not > near to to fetch your data, although this is IMHO possible with FMS etc > volunteers. On opennet we can simply select a different pair of peers every > time to avoid the two nodes converging on each other as they are reused. > What's the point here? Getting some data from the real network to run the simulations? Testing availability of data, paths length, end user experience? I haven't found the old-fashioned threaded-probe-requests you were planning on implementing in your sum up; isn't it something we could use here? NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080710/2161a539/attachment.pgp>
