Since the changes introduced in the 1.1 branch seem to be stable, we're pushing 1.1.3 BETA as 1.2.0 Stable as is. The only real change between these builds is that 1.2.0 does not print debug output to the console per default.
As part of this, the minimum usable version was increased to r69 (1.0.10). The 14 people with older clients will at least have to update to this.
To sum up the changes from 1.0.10 to 1.2.0:
***
The major new feature for 1.2 is static ranges. If a client is assigned a static range, the server will always assume that the client is able to serve files from that range without tracking the files individually. Instead of being pre-distributed, if a file isn't currently cached, the client will proxy-request it from the image servers on-demand, then store it for later use.
Files in a static range will not be tracked by the server, nor will the client bug the server about it when it adds the file or in the unlikely case it decides to delete it. This should greatly reduce the server-side load of tracking clients. It will also allow us to greatly increase the file coverage per region.
Static ranges will only be assigned to faster clients that have a proven track record, and only if it has enough disk space set aside to store all the files for the static range - in other words, 1/65536th of all hosted images. Currently, the minimum requirement is 250 MB disk space and 3 KB/s effective speed per assigned range. A client can be assigned an arbitrary number of ranges depending on its capabilities. Note that static ranges will not be assigned unless the client has been running for 24 hours, and it will only be assigned one range every two hours at most.
A completely new client-to-client speed tester has also been added. This one will be able to detect higher speeds much more reliably than before.
This version of H@H will be able to make advantage of a lot more disk space than before. So if you have loads of it just laying around, it doesn't hurt to bump it up a bit.
- Core: Support for static ranges was added.
- Core: The client will no longer terminate if it fails to set socket buffer sizes for any reason.
- Core: Some platforms didn't like the argument order we used for ping, so this was switched around. (Only relevant for testing against pre-1.1.1 clients.)
- Core: Added user friendly interpretations for a few missing startup errors.
- Core: The stale file pruning mechanism will no longer run if the server hasn't been reachable lately.
- Core: HTTPServer should now recognize IPv6 localhost and private network ranges.
- Core: Removed support for pre-1.0.4 URL format.
- Core: The --use-more-memory mode is now the default. If this causes issues, you can revert to the old behavior with the new --use-less-memory flag.
-- Unless you have physical memory limitations, if you run into Out of Memory errors, you should try using -Xmx1g flag first, which will increase the maximum Java heap space to 1GB.
- Core: Fixed logging could throw a NullPointerException if a null somehow ended up in the final print.
- Core: Added support for multi-threaded client-to-client testing.
- Core: The standard file download mechanism has been rewritten, primarily to support the new testing system. As a bonus, the new one uses significantly less CPU than the old downloader.
- Core: The database schema was altered to remove the unused strlen field. Note that the existing database will automatically be updated on first startup, after which you cannot downgrade without deleting the database.
- Core: The client should now be able to understand requests that use encoded equal signs (=) in the URL.
- Core: The client will now enforce available cache size, and will therefore no longer start if the setting for the cache size is larger than the available disk space minus the total size of the files in the cache. (You can adjust this from the web interface.)
- Core: Added a safety check to prevent the client from starting if it has static ranges assigned but an empty cache, which would indicate some sort of error. (To start a client that has lost its cache, you have to manually reset the static ranges from the web interface.)
- GUI: Workaround for Java 7 randomly failing to return the underlying text of the logging pane when using RDP.
- Downloader: Fixed cutoff for overly long filenames not being applied correctly. (Some poorly written operating systems fail the final file copy operation when total path length exceeds 255 characters.)
- Downloader: HathDL files with gallery names containing tab characters will now be filtered and handled gracefully, no longer causing the downloader to terminate.
- Web Interface: A checkbox for disabling the client-side speed limit was added to the on-site Hentai@Home settings page. This has the same effect as starting the client with the --disable-bwm flag.
- Web Interface: The limit on how much disk space you can assign has been removed.
- Web Interface: Added an option to reset static ranges, for those cases where the cache has been lost for some reason or another.
- Web Interface: Instead of having it as a warning, the interface screen will now simply refuse to change a client's port or key while it is running.
- Dispatcher: The trust mechanics was tweaked to take static ranges into account. Depending on the number of assigned ranges and frequency of requests, a request for a static range file can now cause a slight reduction in trust. The effect should be very minor for well-behaving clients, and is solely to prevent clients with frequent cache wipes from having ranges assigned.
Download from the usual place.For information on how to join Hentai@Home, check out The Hentai@Home Project FAQ.
Hentai@Home 1.2.0, Beta Wrap-Up
Dec 20 2013, 22:19
