Freenet 0.7 build 1112 is now available. It will be mandatory on Thursday so please update ASAP (if your node has auto-update enabled it will do this for you). This build features a number of substantial changes (I apologise for the length of this mail!): - Major changes to HTL (the means by which we limit the number of nodes a request will visit before it gives up): We no longer record the nearest location to the target visited so far. We no longer reset the HTL to the maximum when we get closer to the target than we have been so far. We now have an average of 5 hops at maximum HTL (was 2), followed by 15 hops of declining HTL (was 10). The next build will make this 10 hops at maximum HTL followed by 10 hops of declining HTL. This is to try to get as smooth a transition as possible. The point of all this is to significantly improve request security: the nearest-so-far mechanism gives far too much information to an attacker, and the more hops we do at maximum HTL the better (ideally we'd not have HTL at all, but that would break inserts and make for lots of really short requests). - Support for thread priorities on Linux: We use thread priorities to ensure that the most important jobs get more CPU time. However, this only works on Windows because java uses an API which isn't implemented on Linux. With a helper library (included in freenet-ext.jar edition 19), we set the nice value of each thread to reflect its java-level priority. This, combined with a range of related changes (many of which also affect nodes running on windows), will eliminate the massive spike in ping time that occurs on starting up most linux nodes (and to some degree windows nodes). Because Freenet uses a range of priorities for different threads, you should ideally set its initial nice level to no more than 15, to give it room to maneuver; the unix install script now sets the initial nice level to 12 (the node can make threads more nice but not less nice). - Request cooldown queue: After attempting 3 times to fetch a key, the node will now wait 5 minutes before fetching it again. This will be increased to 30 minutes after I am sure the bugs are worked out. This means that polling apps such as FMS can simply queue their keys with MaxRetries=-1 and not worry about explicit polling. Note that the data will often be found during the cooldown period via ULPRs: this is effectively the client API for ULPRs. - The JPEG filter supports a wider range of images (we had been excluding a lot of encoding formats which were actually necessary for many images).
Apart from the above features, which appear to work in testing so far but probably need further debugging, this build also marks a feature freeze: No major features should be committed to trunk before 0.7.0, please create a branch if you need to work on them. The network coloring code for example will be disabled in 0.7.0 (but maybe just by a flag). Developers should commit major changes as branches so they can be merged after 0.7.0; I will ask them to revert their changes if necessary. Bugfixes are of course always welcome in trunk. Please upgrade, test, and report any bugs you find, preferably to the bug tracker at https://bugs.freenetproject.org/ . -------------- 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/support/attachments/20080219/9887f435/attachment.pgp>
