Hentai@Home

From EHWiki
Jump to: navigation, search

Hentai@Home (H@H) is a Peer-2-Peer gallery distribution system which reduces the load on the E-Hentai Galleries. Current version: 1.2.6.

The client UI.
The client list UI

General Information

H@H is a project that can be compared to a cross between the SETI@home project and BitTorrent.

All participating users run a small Java-based client that downloads files from the main E-Hentai servers to their computer and passes those files on to people who browse the E-Hentai Galleries. This allows E-Hentai to serve many more images using less server bandwidth.

The client may be run freely for any duration of time but it is recommended to run it continuously for as long as possible for maximum rewards.

Signing Up

The H@H application form.

Minimum Requirements

Requirement Notes
Java Runtime Environment
  • Any version higher than 5 is acceptable.
  • Java SDKs are also usable.
3+ Mbit/s burst upload speed
  • A.K.A. 375 Kbytes/s
  • This requirement varies from region to region.
100 MB/hour bandwidth Users may limit how much bandwidth is used per hour if they have a bandwidth cap.
2+ GB of hard drive space SSDs are ideal; write endurance is not an issue.
An open TCP port
A unique IPv4 IP address 1 needed per every operational client.

Obtaining Client Keys

Users who are signing up for their first client simply go to the Hentai@Home page in their My Home area. A flash interface will appear where users may fill in their qualifications. Applications typically take a few days to process.

To sign up for any additional clients, please PM Tenboro. For users wishing to run more than five clients the average quality of their existing clients must be stable above 7,000 before more keys can be assigned.

Installation Guides

Limits

A client's maximum burst speed will determine:

  • The maximum number of connections that can be had simultaneously (up to 500).
Maximum Connections = 20 + max_burst_speed / 10000
  • The maximum disk cache size (in GBs).
Cache Size = max_burst_speed / 10
  • Having static ranges assigned allows a client to exceed this maximum.

Speed Test

When the H@H client starts it contacts one of the H@H control servers which tests the connection of the client in order to check if it can upload data at the configured maximum burst speed. If it cannot the maximum burst speed is reduced internally to the measured upload speed in order to prevent the connection from being overloaded.

It is possible for the measured upload speed to be significantly lower than real upload speed of the Internet connection. In such a case the H@H client will be underused and its owner can request a speed test override from Tenboro by sending proof (e.g. a screenshot of their SpeedTest's results).

Activity

An H@H client needs to maintain a Trust of 0, Quality of 2,500, a cache of 2 GB, and max tested speed of 80 KB/s. Failure to reach any of these requirements will make it idle on the network and wait until the requirements are reached.

Scheduler

Each client can be scheduled to use less than its maximum burst speed and bandwidth. These can be based on particular days but are limited to using precise times (every hour on the hour). Schedules are read and cached at the start of each hour so changes won't apply until the start of next hour.

Software

A few command line switches may be given to the H@H application in order to change some of its behaviors:

--disable_bwm
Disables the bandwidth monitor which is the part that makes sure the H@H application does not use more upload speed than the value of the "Maximum Burst Speed" parameter. When the bandwidth monitor is disabled, the H@H dispatcher will still respect the "Maximum Burst Speed" parameter so that the mean upload speed of the H@H application won't exceed the value of that parameter. However, the H@H application might use as much upload speed as the Internet connection on which it runs can provide in order to send image files, which generally results in upload peaks.
In some cases, the bandwidth monitor is unable to use the whole maximum upload speed that has been set, which can result in an under-utilization of the H@H application upload speed (and might trigger false overload notifications). In such cases, it is better to disable the bandwidth monitor in order for the H@H application to give better performances.
--disable_logging (This can also be set from your client's settings page)
Disables the writing of log entries in the log_out file. Enabling this switch might increase the performance of the application by reducing its I/O usage.
--force_dirty
Forces a check of the database for errors (as if the database was dirty).
--max_connections=conn
Sets the maximum number of connections the application can handle to conn. The default maximum number of connections depends on the max burst speed parameter, and is computed as detailed above. In some rare circumstances the default value is too low and the maximum number of connections needs to be increased slightly in order to avoid triggering false overload notifications. Setting this value to a too high limit might have severe consequences on a client's performance, and impact the whole H@H network badly. DO NOT CHANGE THIS VALUE UNLESS YOU ABSOLUTELY KNOW WHAT YOU ARE DOING!
--port
Overrides the port set in the client's settings. This allows running H@H on port 80 on Linux as a non-priviledged user. This can be achieved by adding the following rules to iptables:
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 7777 -j ACCEPT
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 7777
--silentstart
Starts the UI in minimized mode (tray icon).
--skip_free_space_check
Disables the free space check so that the application won't err if the space left on the partition that contains the cache folder is less than the configured parameter (or 100MB if that parameter is set to a value less than 100MB).
--use_more_memory (Depreciated; H@H now uses more memory by default, but this can be disabled through your client's settings page)
Allows the application to use more memory in order to increase its performances (by reducing the number of I/O operations). More specifically, the application will use more memory when building the cached files list, sending the file's content, and it will use a memory cache in order to reduce the number of times the files' access timestamps are updated in the database.
--verify_cache (This check can also be ordered from your client's settings page)
Forces a check of the entire cache. This is the same as --force_dirty, except that the content of each file in the cache is also checked (which can take a lot of time).
-Xmxmemm
Limits the use of memory to mem (in MB).

Cache

The system will fill a client's cache with in-demand files and will delete least recently used files once it fills up to the set capacity. It is important for users not to manually tamper with any files in the cache as this will cause major trust and cache database issues for the client. Corrupted files will be deleted and replaced if requested although the client will lose some trust.

Static Ranges

Clients have static ranges of content (~175 MB each, or 1/65536th of the site's "active" content) assigned to them. The server will always assume that the client is able to serve files from that range without tracking the files individually. If a ranged file isn't currently cached the client will proxy-request it from the image servers on-demand and store it for later use.

Clients that have started for the first time are assigned 5 ranges. From there up to 48 new ranges can be assigned every day (assuming good performance and available capacity). The ranged files will stay in the client's cache for 90 days after they were last requested. A client may have up to 5,000 ranges total.

Trust

Trust indicates how well the client is performing according to other clients. Trust gradually rises by 1-4 per minute if the client is behaving normally, even if it is not serving files. Negative trust often occurs from improper shutdowns or bad connections. Trust caps at +1000.

Quality

Quality measures the long-term overall stability and reliability of a client up to a value 10,000. It prioritizes clients for file requests (along with raw speed and proximity factors).

  • New clients and clients that have been unused for several days will start out with 0 quality; it can take several days for it to stabilize at the baseline value.
  • What constitutes a decent quality rating varies between geographical regions.
  • Clients that perform below 5,000 will have their static range factor for hath calculation reduced.

Rewards

Users receive 1 GP for each hit on their client, as well as be able to compete for a position on the H@H toplist.

The currency known as Hath is also be generated (internally calculated roughly every minute), which can be used to purchase Hath Perks. The minimum speed required to earn hath is 40 KB/s. The amount that can be earned per day per client is based on average hit/minute (calculated over a week) and static ranges.

Free Archives

Each client that runs for >24 hours and has a hitrate of 1+ earns a quota of 1 GB/day in free archive downloads. An additional +10 MB/day is earned per adjusted average hit.

  • This quota is measured over a 7-day sliding window.
  • Recreated archives do not qualify.
  • The amount a user has earned can be found in their H@H client list page at the bottom of the "Your Active Clients" section.
  • The quota is disabled when a client is suspended or shut down for up to 4 hours, and is re-enabled when a client comes back online.

H@H Image Proxy

To use H@H as a proxy for the galleries, users simply need to enable it through their My Settings page. This enables any images viewed in galleries to be loaded through the H@H client. As such, these images are added to the user's H@H cache, making them instantly (re)viewable as long as they remain cached.

See also

Forum Links