On Thursday 08 May 2008 23:22, Matthew Toseland wrote:
> 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.
>
Token passing load limiting. Just how important is this? It's likely to be a
fair amount of work - we need to figure out a way to simulate it first off!
It would give us more control over load management, hopefully enable us to
use more bandwidth on faster nodes, might improve routing slightly, and have
some security benefits... otoh the current code is *mostly* working
adequately... My inclination is to postpone this for now, unless somebody
wants to make a serious effort at simulating it?
-------------- 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/20080509/10802c67/attachment.pgp>
