I've made a bug on the bug tracker to which I've linked all the things that I think *might* be important for 0.7.1. Please contribute to this bug by setting it related to anything that you think it should be related to, or reply to this thread.
Stuff I think is important for the next release: Automatic bandwidth calibration. Other p2p apps have this, we should have it. It should significantly improve the average output bandwidth available, since most users presumably don't set the output limit. Further it would improve usability by making the connection more responsive. Timescale: Unclear at this point. Priority: High. Datastore changes: It looks very much like we can have both better network performance and much less memory overhead by using a non-associative salted hash table on disk. Daniel Cheng (sdiz) is currently implementing this on a branch. I will be reviewing the code soon. Nextgens has asked about its suitability for the cache as opposed to the store; mrogers' simulations were based on it being for the store. Timescale: A lot of this is done already, most work will be sdiz's. Priority: High. More work on ULPRs: Various changes related to coalescing and temporarily suppressing requests if there are too many for a single key over a period. Should help with FMS and to boost payload %. Timescale: 1 week Priority: High. Use peers' peers' locations for routing: According to oskar and vive, this should significantly cut average path lengths. There is minimal security impact as this data is already exposed by swapping. Timescale: 1 week Priority: High. Faster swapping: Vive has some ideas to improve swapping performance significantly. Hopefully he can turn these into implementible proposals. This would significantly improve performance (especially given the level of churn we see), and also help with security (because we could reset more to prevent swapping attacks). Timescale: Depends on Vive. Implementation probably relatively easy. Priority: High if possible. Would justify calling it 0.8.0 IMHO. Streams and MTU: We can improve our payload proportion significantly, allow for much smaller packets, support smaller MTUs, avoid padding with random data, and support simple stego, by implementing transport layer streams. There are also a number of other mostly minor changes which we should implement to make Freenet work well on low MTU connections. Timescale: 2-4 weeks?? Priority: High. Better Librarian integration: We should have a search box on the homepage, it should be embeddable in freesites. And XMLSpider probably needs some more debugging. Timescale: 1 week or less. Priority: High. Client layer changes: I propose to move the entire client layer onto disk. We would continue to store enough data to restart requests from scratch in downloads.dat.gz, but we would have an on-disk queue structure instead of an in-memory queue structure. This combined with the datastore changes would make our memory usage fixed, regardless of the size of your store or the number of requests you queue. It would solve many bug reports, it would incorporate the long-awaited true request resuming, would make Freenet run well on home servers with 128M or maybe even 64M of RAM, and generally is a good idea. Timescale: 2 weeks?? Priority: Medium. Auto-update for plugins: We should have had this ages ago. Several people have been complaining about it, it is a security issue if you want them kept up to date. It shouldn't be difficult. Timescale: 3 days Priority: Medium. Better content filter: Filter on insert by default (for performance on fetch), support more HTML etc, support RSS, support some other formats (e.g. mp3), etc. Timescale: 1 week, more for more formats. Priority: Medium. Better USKs: Hierarchical DBRs would help USK lookups to find something close to the latest version quickly, then plod through the editions from there to find the latest version. Timescale: 2 days. Priority: Medium. System tray icon: IMHO this would be a good usability feature. It would make it obvious that Freenet is running in the background and make it easy to throttle it or disable it when you want to play an MMORPG etc. Timescale: 1 week??? Priority: Medium. Bandwidth: mister_wavey is working on a bandwidth scheduler. It would be a big help for a lot of users who have off-peak quotas etc. There will be a user friendly config sub-page for it. Average bandwidth limits, maybe actually telling the node a monthly quota, would also be useful for many users. More accurate bandwidth limiting (limiting all packets not just transfers) would also be a big help for users on slower upstream connections. Timescale: Unknown. Priority: Medium. Allocate temporary files out of a small number of blob files: Further reduction in memory usage, some other benefits, cuts the number of fd's we use (thus allowing more FEC threads on mutli-core systems), easy. Timescale: 3 days Priority: Low. -------------- 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/20080508/099dc9fb/attachment.pgp>
