[freenet-support] Freenet 0.7 build 1112 - big changes and feature freeze

[Matthew Toseland]

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 : http://emu.freenetproject.org/pipermail/support/attachments/20080219/9887f435/attachment.pgp