Hentai@Home

Hentai@Home (H@H) is an open-source Peer-2-Peer gallery distribution system which reduces the load on the E-Hentai Galleries. The current version can be found in the update announcement thread.

The client UI (maximized)

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.

Signing Up

The H@H application form.

Minimum Requirements For New Clients

Requirement	Notes
Java Runtime Environment	Version 8 or newer The JDKs are also usable.
80+ Mbit/s measured speed	At least 2500KB/s must be dedicated to H@H This applies to both upload and download.
1000 GB/month data transfer	Users may limit how much data is used per month. Note that this limit is approximate.
10+ GiB of dedicated hard drive space	SSDs are ideal; write endurance is not an issue. At least 1 GiB for every 0.2 Mbit/s is encouraged for optimal static range allocation. Please ensure the client can sustain both speed and disk I/O in the long run.
An open TCP port	443 recommended; otherwise must be between 1024-65534. Unregistered IANA ports or UNIX kernel ports are recommended as private ports. Check this list for potential port conflicts. Some ports are not permitted.
A unique IPv4 IP address	1 per every operational client. Ideally should be static, or needs to be relatively stable (i.e. not change constantly).
Uptime	A single client should remain online for at least 90% of the time over a 6 month period. Clients that have an unacceptable level of downtime will be revoked. If a client remains offline for more than three months, it will be deleted and cannot be recovered.

Obtaining Client Keys

Users wishing to sign up for their first client can apply from the Hentai@Home page in their My Home area. Applications are typically processed in less than a day.

For any additional clients you will need to PM Tenboro. For users wishing to run more than 5 clients the average stable quality of their existing clients must be 7,000+ before more keys are assigned.

Installation Guides

• Windows
• FreeBSD with Jails
• Daemonizing H@H on BSD
• Linux
  • Ubuntu
  • Debian
  • Debian on Raspberry Pi
  • Solaris
• Rented Server
• Python Client

Limits

A client's maximum burst speed (in KB/s) will determine the maximum number of connections that can be had simultaneously (up to 500 at 4800 KB/s or more).

Simultaneous connections are determined by a client's hitrate and burst speed (during speed tests, the packet size is adjusted to match the client's burst speed).

Maximum connections (capped at 500) = 20 + max_burst_speed / 10000

The disk cache size (in GB) must be enough to maintain static ranges. Clients must be able to store 10 GB or 250 MB per static range at any given time, whichever is higher:

Minimum cache size = max(10, static_ranges * 250 / 1024)

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.

Activity

A client is considered to be "healthy" if all of the following apply:

• The client must be running and not suspended.
• The client's trust value must be above 0.
• The client must maintain a quality of more than 2000.
• The client's tested speed must exceed 400 KB/s (for Asia clients) or 800 KB/s (for non-Asia clients).

Failure to reach any of these requirements will make it idle on the network and wait until the requirements are reached.

Data Transfer Cap

With each client, you may define a Monthly Data Transfer Target from the client's settings page (under the "Advanced Settings" section). This will help to prevent H@H from using more data than the monthly cap set by your ISP.

• If the system detects that you are likely to exceed this target, it will reduce the priority of ranges on your client to reduce the load, but it is not guaranteed to stay below this value.
• The value must be at least 1000 GB if set.
• If a limit is set, the static range allocation of that client will be limited to 1 per 5 GB.
  • If set below 5000 GB/month, the client will not be assigned any high-capacity ranges, and all previously assigned high-capacity ranges will be removed immediately.

Software

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

--disable_bwm

(Can also be set from the client's settings page)

Disables the bandwidth monitor, which prevents the client from using more upload speed than the value of the "Maximum Burst Speed" parameter. The H@H dispatcher will still respect the "Maximum Burst Speed" parameter so that the mean upload speed of the client won't exceed that value. However, the client might use as much upload speed as its connection provides in order to send 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 client's upload speed (and might trigger false overload notifications). In such cases, it is better to disable the bandwidth monitor in order for the client to give better performance.

--disable_logging

(Can also be set from the client's settings page)

Disables the opening, creation, and writing to the log_out file. This will significantly reduce I/O for HDD but make network troubleshooting harder. Java errors will still be logged to log_err.

--flush-logs

Flushes the log to disk for every written line. This will increase I/O; mostly recommended for when the log is written to a ramdisk.

--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, 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 too high 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. For example, one may use this option and the following iptables rules to allow running H@H on one port officially (in the settings page) whilst binding or tunneling a completely different port. One potential use case cloud be: configure H@H in the setting to start on port 443 (HTTPS), then use --port=7777 with the following iptables rules:

iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 7777 -j ACCEPT
iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 7777

--rescan-cache

Checks the cache for errors.

--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).

--verify_cache

(Can also be requested from the client's settings page)

Forces a check of the entire cache. This is the same as --rescan-cache with the addition that the SHA-1 hash of each file is also checked; this can take a long time.

--disable-ip-origin-check

Disables the requirement that RPC server requests come from a whitelisted IP. Using this is discouraged as it reduces security, but may allow the client to work in some common non-transparent proxy configurations.

--disable-flood-control

Disables the rate limit on connections per IP address. May be necessary to use with the above trigger.

Directories

--cache-dir

--data-dir

--download-dir

--log-dir

--temp-dir

These arguments allow for changes to the locations of these directories. Quotes are required if there are spaces in the path. H@H will attempt to create the directory if it does not exist. Only log and temp may share a directory.

Examples:

Windows: --download-dir="c:\some download dir with spaces\"
Linux: --cache-dir=/some/cache/location --temp-dir=/dev/shm/hath --log-dir=/dev/shm/hath

Cache

The system fills a client's cache exclusively with static ranges of files. Users should not tamper with any of these files; this will cause major trust and cache database issues for the client. Corrupted files will be deleted and replaced if requested.

Static Ranges

Static ranges each correspond to 1/65536th of the site's content. 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.

The assignment of static ranges for a particular region is based on a scoring algorithm. It generally prioritizes new clients or clients with few ranges, assuming all other factors (e.g., tested speed) are similar across clients. If a static range has only been assigned to less than the desired number of clients or a below-average number of clients, the range in question will be assigned to an available client.

Static ranges are divided into priority levels, where P1, P2 and P3 are considered "active" ranges. The network will first attempt to request a file from a P1 client, and then fall back to clients with a lower priority if the initial client(s) fail to serve the file.

The final priority level P4 is for "dead" ranges that previously active ranges can be demoted to, for example if the client if offline for an extended period of time.

To receive the most P1 ranges, the client should maintain a high tested speed and quality value, and have as high uptime as possible. Clients that experienced recent overloads will be less likely to be assigned with P1 ranges.

Clients cannot be assigned more ranges if they fail the minimum trust, quality, current/previous session runtime, or tested speed requirements.

High-Capacity Ranges

Static ranges can also be promoted into High-Capacity (HC) ranges, in which the client will be used to serve large and original quality files of that range.

To receive any HC ranges assignment, clients must meet more stringent requirements:

• Must be located in one of the three major regions with surplus capacity. i.e., Europe, North America, or Asia (excluding mainland China)
• Must have at least 10000 KB/s throttle and 8000 KB/s tested speed
• Must have the monthly bandwidth limit set to either unlimited (0) or at least 10000 GB/month
• Must have at least 100 GB of disk space assigned

The maximum number of HC ranges that a client can have is limited to 1 per 1 GiB of reserved disk space. You will lose all of your assigned HC ranges if you set a data transfer cap below 5000 GB/month or reduce the maximum upload rate below 10000 KB/s. The traffic estimates for calculating Hathrate will also be reset.

Due to their surplus cache capacity, clients with a low ratio of P1 ranges will be preferred for HC range promotions. Do NOT attempt to avoid P1 assignments for the sake of gaining HC ranges, as they are still preferable over HC ranges.

Note that HC ranges are set independently of priority, meaning a static range can both have a priority of P1 and be set as an HC range.

Trust

Trust indicates how well the client is performing according to other clients.

• Trust caps at +1000 and 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, bad connections, or having a higher than expected number of cache misses.

Quality

Quality measures the long-term overall stability and reliability of a client, calculated by comparing the client's average failure rate to the average failure rate of the region. It influences the assignment/promotion of static ranges, as well as the allocation of traffic.

• If the client's average failure rate is the same as the regional average, the quality metric will be at 9000. To achieve maximum quality (i.e., 10000), the client would need to have less than half the failure rate compared to the average.
• If the quality drops below 2000, the client will stop receiving traffic until it recovers.
• New clients with minimal traffic may experience some fluctuations in the value, but this will stabilize over time.
• Due to the quirkiness of the region, clients located within the Chinese Dominion region (i.e., mainland China) do not use the quality metric. The value output is locked at 10000 on the user end.

Rewards

Users receive 1 GP for each hit on their client and may compete for a position on the H@H toplist. While running healthy H@H clients, users receive Hath which can be used to purchase Hath Perks.

The daily Hath earned per client is based on the following formula:

Hathrate/day = 1 + 0.15 * max(hits_per_minute, KB_served_per_minute / 420) + 0.025 * active_rangecount + 0.05 * hicap_rangecount

• The contribution from assigned ranges is capped by the client's tested speed. The cap is set to tested_speed / 100 KB/s.
• The Hath is made available roughly every 4 hours the client has been running.
• Only healthy clients which current or previous session lasted for at least 24 hours straight will generate Hath.
• Clients will not receive any Hath if the quality drops below 2000.

H@H Downloader

For more information, please check this thread.

An H@H client can be used to download archives (instead of via HTTPS).

• Resolution options include 780x, 980x, 1280x, 1600x, 2400x, or original (availability may differ).
• Once queued there is no way to prevent the client from downloading the gallery.
• A galleryinfo.txt file is generated upon completed unlike archive downloading.
• Filename changes still occur.
• These downloads still cost GP/credits (see below for exceptions).
• The download queue is server-side and as such is not affected by client-side interruptions. It will resume if the client is restarted. Queued downloads aren't pruned unless the client fails to download them for a full week. The client will verify that the downloaded file has the expected hash at completion.

Free Archives

Healthy clients with its current or previous session lasted for at least 24 hours straight earn a quota of 1,000 MB/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.
• Extra clients do NOT earn another 1,000 MB.
• The amount a user has earned can be found on their H@H client list page at the bottom of the "Your Active Clients" section.

Revocations

Clients that fail to adhere to the uptime requirements by a significant margin or have their cache/ranges regularly cleared will be revoked. Revoked clients can no longer be used and will be deleted after the three month grace period.

Depending on what led to the revocation, revoked clients can sometimes be reactivated. You would need a very good reason for this to happen, and this will be decided on a case by case basis. "I did not read the requirements on the signup page nor the multiple automated warnings I received" is not a good reason.

If your client is revoked, you will not be able to re-apply to H@H in the future.

See also

• FAQ - Hentai@Home
• Technical Issues - H@H
• Hath
• Downloading
• Renting A Seedbox

Forum Links

• H@H FAQ topic
• Running H@H as a Service
• Tenboro's post detailing the limitations regarding the allocation of static ranges