On Thursday 10 July 2008 10:44, Florent Daigni?re wrote: > * 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!
We did debate it (briefly) at the summit. Ian (was it Ian?) was of the view that there are still too many steps involved in the installation process and this is confusing new users. > > That said I'm more than happy to hand over the maintainance of the > installer :p I'll bug you if I don't understand something. Which is most of the installer still. :) > > > 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. Agreed. > > > 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. It works for other p2p's. What specifically is the problem for Freenet? Small number of connections? > > > 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. How is it related? > > 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. And how exactly do you propose we figure out the MTU from Java? More JNI? :( > > > 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? They were implemented some time ago. They don't tell us anything about data reachability. > > NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080710/8d5aa0c7/attachment.pgp>
