Enter The Freenetrix
The Freenet Help Site
Enter The Freenetrix
Licences used on this wiki
Welcome admin to Freenet WikiServer
Edit Page - Diff - Revisions - Title Search - Preferences - Bottom
 
Latest stable build is 5103 (20 Jun 2005)

5100: The latest stable build
Freenet stable build 5100 is now available. The snapshots have been updated. Please upgrade.
Changes:
  • Removed the (primary) failure table. This may have been causing many fast DNFs recently on files that may well actually be available, but which through getting requests and failing have gotten into the failure tables on many nodes. There is a risk that removing the failure table may increase network load; if this happens, we have various options for dealing with it. Until recently there were very few files blocked by the failure table, but there have been recent reports of large numbers of blocks, possibly caused by increased node specialization.
  • Minor client-layer bugfixes - Null Pointer Exceptions in Segment Output Stream turned into error messages. I haven't fixed the underlying cause of the error messages yet, but things should work better with the errors than with the NPEs (which were also errors!).
5099
This version performs a network reset. This means that if you are running an earlier version you cannot communicate with nodes running 5099 and they cannot communicate with you. This means that you will NOT see a 'latest version' on your web interface display.

Thanks to all who helped to test 5097, 5098 and 5099. Thanks partly to their efforts, this build appears to have greatly improved insert performance relative to 5096. You will be able to use the update utility on Windows, or update.sh on Linux. If this does not work, for example if your node connects to zero nodes
after startup, download seednodes.ref manually from http://freenetproject.org/snapshots/ , and save it over your existing seednodes.ref . If you can't use the updater you will also need to get freenet-latest.jar, which replaces freenet.jar. In any case you will need to turn off the node before updating.

The changes in this build are numerous, the highlights:
  • Much better insert performance due to numerous bug fixes, some of which were quite serious, and some minor architectural changes relating to inserts.
  • New simulator application merged to stable. Not usable by most end users, but has been producing a lot of interesting results for us. Please do try to publicise the simulation; when we have some more results we will put up a page showing our findings, with lots of graphs.
  • Lots of minor code cleanups.
  • A few other minor changes.
5098
5098 is now available but you will need to download and install it manually. (The automatic updaters will be available once enough people have manually switched.) This version performs a network reset. This means that if you are running an earlier version you cannot communicate with nodes running 5098 and they cannot communicate with you. This means that you will NOT see a 'latest version' on your web interface display.

Because this effectively splits Freenet into separate 'nets it is important for everyone to upgrade as soon as possible. To do so:
Download http://freenetproject.org/snapshots/freenet-5098-reset.jar and save as freenet.jar over your existing file and download http://freenetproject.org/snapshots/reset-seednodes.ref and save as
seednodes.ref over your existing file.

5098 fixes many insert problems, and testing on a small network before and after the fixes is very promising.

5096
Freenet stable build 5096 is now available. The snapshots have been updated. Please upgrade to 5096, test it, and report any bugs that you find. You can do this by using the update utility on windows (on the start menu), or by running update.sh in linux, or by downloading the new jar from http://freenetproject.org/snapshots/freenet-latest.jar. Either way, it's probably a good idea to shut down the node before doing so (and turn it back on afterwards!).

There are many changes in this build, here are some of them:
  • 5095 is now mandatory. Queueing wasn't really working adequately until 5095. However the overwhelming majority of nodes at least in my RT are 5095, so there is hopefully no problem here...
  • Lots of work on timeouts, in response to recent problems with inserts. It is likely that the recent insert problems have been caused by insert timeouts being wrong, partly by not taking queueing into account.
  • A major routing bugfix in the estimator smoothing code. This is used mostly when a node is relatively young.
  • New, optional, but enabled by default, super-fast routing estimators. These are slightly lower precision than the original estimators, and were developed as part of the recent simulation efforts. These are based on double precision arithmetic (64 bits, 53 of which are "mantissa" i.e. actual value, we can use), which is accelerated in hardware by most modern CPUs, instead of 160-bit Big Integers. We believe that doubles provide sufficient precision; the simulations suggest there are no serious bugs in the changeover of this particular code. 53 bits should be enough even for a very large network... In any case the new code is 3-4x faster (in terms of CPU usage, not routing effectiveness or how fast it learns). This is a big part of freenet's overall CPU usage, so expect improvements, especially on low end machines. Turn this off by setting useFastEstimators=false in freenet.conf/freenet.ini.
  • Also you can use doEstimatorSmoothing to enable or disable estimator smoothing; the results from the simulations on estimator smoothing are unclear at present.
  • Transfer failures are handled better by Fproxy, there is now a proper error message instead of the unfriendly exception messages we have been seeing reported on devl and support recently.
  • Much improved Current Downloads page thanks to Iakin (Niklas Bergh). And related bugfixes.
  • Partial fixes and workarounds for the "Too high probability" bug. I don't think we have finally fixed the cause of this bug, but at least it will be recovered from virtually instantly. We may have fixed it completely however.
  • We now have a histogram of the versions of only connected nodes, as well as the histogram of versions of all nodes in the routing table.
  • Added some missing images for the "simple" theme (UITemplateSet=simple).
  • Lots of routing refactoring by Thelema (Edgar Friendly).
  • Workaround for an infinite loop bug in queueing that I haven't been able to reproduce and fix yet. Will log an error if it happens.
  • Workaround for a bug in some Sun JVMs, that causes Big Integer.toString(16) to cause an NPE. We now use our own code to dump Big Integers.
  • Fix a rare NPE in Mux Connection Handler
  • Extra checks for invalid MRIs
  • Added a method to Auto Requestor to calculate the CHK we would get if inserting a file, given a specific content type, by Vesa Salento. I think this may make freenet.client.cli.Main computechk work correctly, but I haven't tested this.
  • Paranoia to ensure we never send an HTL over our limit. I don't think current builds do this; I know some older ones did.
  • start-freenet.sh was still not setting LD_ASSUME_KERNEL for some systems. Fixed it.
  • Many other minor fixes.

5095
Freenet stable build 5095 is now available. Please upgrade, test, and report bugs.

To upgrade:
On Windows, use the update option on the start menu, if it is there.
On linux, stop the node, run update.sh, and start it.
On any platform, stop the node, fetch http://freenetproject.org/snapshots/freenet-latest.jar and overwrite your existing freenet.jar with it, then restart the node.

This bug fixes some more queueing bugs, which may have caused the node to go into an infinite loop running the queue, or responding very slowly, using 100% CPU, not responding to the web interface, and not sending any requests.

I apologize for the recent flood of new stable builds; queueing was a fairly significant change architecturally despite not being much code; thus we have some new bugs, some of which are quite significant. Not much work has been done to optimize queueing's CPU usage yet; if you have problems with this please tell us, and we will be more likely to do something about it. Optimizations would probably introduce more bugs, so haven't been an immediate priority...


5094
Freenet stable build 5094 is now available. The snapshots have been updated. Please upgrade, test, report bugs. Especially if you are in the seednodes generator list.

To upgrade:
On Windows, use the update option on the start menu, if it is there.
On linux, stop the node, run update.sh, and start it.
On any platform, stop the node, fetch http://freenetproject.org/snapshots/freenet-latest.jar and overwrite your existing freenet.jar with it, then restart the node.

Major changes:
  • Improvements to seednodes generation system
  • Nodes were being left out of the seednodes because we'd never connected to them (they connected to us), and nodes were being included despite not being connected (if we've previously connected to them).
  • Fix for a bug that caused fproxy requests to freeze
  • Transfer failures weren't being handled properly; they've been fatal for the last few months, but the internal client side doesn't know this
  • This caused fproxy requests to just stop, and never succeed or fail, taking up a thread forever. This could easily have caused the web interface to stop responding, and the number of threads used will have slowed the node down.
  • This probably has effects on FCP as well but I haven't investigated them yet.

5093
Freenet stable build 5093 is now available. The snapshots have been updated. Please upgrade, test, report bugs.

To upgrade:
On Windows, use the update option on the start menu, if it is there.
On linux, stop the node, run update.sh, and start it.
On any platform, stop the node, fetch http://freenetproject.org/snapshots/freenet-latest.jar and overwrite your existing freenet.jar with it, then restart the node.

Major changes:
4 major bugfixes to queueing.
  • We would sometimes send a request back to the node the request had been received from.
  • We would sometimes send a request to a node we had already routed it to.
  • Timeouts were wrong for local requests.
  • The send request counter was not being updated. This could cause permanently high load, which would cause high MRIs and nodes to effectively freeze up, eventually accepting virtually no queries.