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.
Minimum Requirements For New Clients
|Java Runtime Environment||
|80+ Mbit/s measured speed||
|1000 MB/hour bandwidth||Users may limit how much bandwidth is used per hour (SSL overhead is not counted).|
|10+ GB of dedicated hard drive space||
|An open TCP port|
|A unique IPv4 IP address||1 per every operational client. Should be static.|
|Uptime||A single client should remain online for ~75-80% of the time over a 6 month period.|
Obtaining Client Keys
Users 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.
For any additional clients please 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.
- FreeBSD with Jails
- Rented Server
- Python Client
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 = 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)
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.
An H@H client needs to maintain a Trust of 0, Quality of 2500, and tested speed of 400 KB/s. Failure to reach any of these requirements will make it idle on the network and wait until the requirements are reached.
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.
A few command line switches may be given to the H@H application in order to change some of its behaviors:
- (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 performances.
- (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.
- 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.
- 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!
- 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 tunnelling a completelly different port. This usercase is seldom but an example cloud be: configure H@H in the setting to start on port 6000, then use --port=7777 with the following iptables rules:
iptables -A INPUT -p tcp --dport 6000 -j ACCEPT iptables -A INPUT -p tcp --dport 7777 -j ACCEPT iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 6000 -j REDIRECT --to-port 7777
- Checks the cache for errors.
- Starts the UI in minimized mode / tray icon.
- 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).
- (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.
- Limits the use of memory to mem (in MB).
- 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.
- Disables the rate limit on connections per IP address. May be necessary to use with the above trigger.
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.
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
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 each correspond to 1/65536th of the site's "active" 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.
Clients that have started for the first time are assigned 20 ranges. Ranges are capped based on the low-end quality mark of the client. A client won't be assigned any new ranges if the tested speed drops below 800kB/s. The amount of ranges a client can have is capped to 1 per kB/s of effective speed (the lesser of throttle and quota per hour) and one per 250MB of allocated size.
Clients experiencing connectivity issues during peak hours will receive less static ranges to avoid increases in hitrate and workload they would otherwise not properly manage.
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 measures the long-term overall stability and reliability of a client, calculated by comparing the client's average failure rate with its average hit rate. It prioritizes clients for file requests (along with raw speed and proximity factors) and determines how many static ranges can be assigned every day when compared with the region's average performance.
- Quality gradually increases as long as the client is properly serving files. It fluctuates using a weighed average of low and high marks to measure a client's long-term stability. Those marks stabilize over time unless network issues exist. The low-end mark defines daily static range assignment.
- What constitutes a decent quality rating varies between geographical regions. A client's low-end mark should be at least within its regional average in order to get the most static ranges.
|7,000||Static Range cap becomes 6,000.|
|5,000||Static Range cap becomes 2,000. Its factor for hath calculation is reduced.|
|3,000||Static Range cap becomes 1,000.|
|2,500||Client stays idle.|
|1,500||Starting point for new clients or those that have been unused for several days.|
While running H@H clients that meet the minimum speed requirements users receive Hath which can be used to purchase Hath Perks. Clients must be able to hit at least 400 KB/s to award any Hath. The daily amount earned per client is based on average hit/minute (calculated over a week) and static ranges. The hath is made available roughly every 4 hours the client has been running.
A quality rating below 5000 reduces the static range gain by a linear factor:
Hathrate/day = 1 + 0.15 * hitrate + 0.01 * static_ranges * min(1, low_quality_factor)
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.
Functioning clients earn a quota of 1,000 MB/day in free archive downloads. An additional 10 MB/day is earned per adjusted average hit.
A client is considered functional if all 4 of the following apply:
- The client scores an average hitrate of at least 1.0 hit/minute.
- The client has been running for at least 24 hours straight.
- The client had no more than one downtime within the same hour.
- The client had no downtime that exceeded 4 hours.
- If a client breaks either of the last 2 conditions its the uptime is reset and it must remain active for 24 hours again to qualify.
- 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.
- H@H FAQ topic
- Running H@H as a Service
- Tenboro's post detailing the limitations regarding the allocation of static ranges
|E-Hentai Galleries Navigation|
|Finding||Gallery Searching • Bounty System • Favorites • Making Requests|
|Directory||Anthologies • Artist Recommendations|
|Uploading||Making Galleries • Gallery Categories • Gallery Manager • Gallery Descriptions|
|Downloading||Archives • Hentai@Home • EHTracker • Gallery Readers|
|User Actions||Tagging||Fetish Listing • Know The Difference • Mechanics (Namespaces) • My Tags • New Tags|
|Other||Commenting • Expunging • Mod Power • Rating • Renaming • Reporting|
|Rewards||Credits • Gallery Points • Hath Perks • Toplists|
|Viewing||Lo-Fi • Multi-Page Viewer|
|System||API • Bans • FAQ • My Home • Technical Issues|