Hentai@Home - Revision history

Kagoraphobia: /* High-Capacity Ranges */

2026-03-18T08:24:31Z

High-Capacity Ranges

← Older revision		Revision as of 08:24, 18 March 2026
Line 161:		Line 161:

	To receive any HC ranges assignment, clients must meet more stringent requirements:		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 China)		*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 at least 10000 KB/s throttle and 8000 KB/s tested speed
	*Must have the [[Hentai@Home#Data_Transfer_Cap\|monthly bandwidth limit]] set to either unlimited (0) or at least 10000 GB/month		*Must have the [[Hentai@Home#Data_Transfer_Cap\|monthly bandwidth limit]] set to either unlimited (0) or at least 10000 GB/month

Kagoraphobia: /* Quality */

2025-08-07T08:37:01Z

Quality

← Older revision		Revision as of 08:37, 7 August 2025
Line 182:		Line 182:
	*If the quality drops below 2000, the client will stop receiving traffic until it recovers.		*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.		*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]]==		==[[Rewards]]==

Kagoraphobia: /* Minimum Requirements For New Clients */

2025-07-30T15:10:10Z

Minimum Requirements For New Clients

← Older revision		Revision as of 15:10, 30 July 2025
Line 44:		Line 44:
	\|-		\|-
	\|A unique IPv4 IP address		\|A unique IPv4 IP address
	\|1 per every operational client. ~~Should~~ be static.		\|1 per every operational client. Ideally should be static, or needs to be relatively stable (i.e. not change constantly).
	\|-		\|-
	\|Uptime		\|Uptime

Tenboro at 17:56, 8 December 2024

2024-12-08T17:56:49Z

← Older revision		Revision as of 17:56, 8 December 2024
Line 1:		Line 1:
	Hentai@Home (H@H) is an open-source Peer-2-Peer gallery distribution system which reduces the load on the [[E-Hentai Galleries]]. ~~Current~~ version: [https://forums.e-hentai.org/index.php?showtopic=234458 ~~1.6.2~~].		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 [https://forums.e-hentai.org/index.php?showtopic=234458 update announcement thread].

	[[Image:H@H Client.png\|thumb\|The client UI (maximized)]]		[[Image:H@H Client.png\|thumb\|The client UI (maximized)]]
Line 123:		Line 123:
	::(''Can also be requested from the client's settings page'')		::(''Can also be requested from the client's settings page'')
	::Forces a check of the entire cache. This is the same as <tt>--rescan-cache</tt> with the addition that the SHA-1 hash of each file is also checked; this can take a long time.		::Forces a check of the entire cache. This is the same as <tt>--rescan-cache</tt> with the addition that the SHA-1 hash of each file is also checked; this can take a long time.
	~~:<tt>--Xmx''mem''m</tt>~~
	~~::Limits the use of memory to ''mem'' (in MB).~~
	:<tt>--disable-ip-origin-check</tt>		:<tt>--disable-ip-origin-check</tt>
	::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 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.
Line 147:		Line 145:

	===Static Ranges===		===Static Ranges===
	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.		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.		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.

	~~Ranges~~ are ~~capped based on the low-end [[#Quality\|quality]] mark of the 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.
	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 at 1 per 5 KB/~~s ~~of effective speed (~~the ~~lesser of throttle and quota per hour) and one per 250MiB of allocated size.~~
	~~Each client can only have 6000 ranges assigned at max~~.

	~~Clients experiencing connectivity issues during peak hours will receive fewer static~~ ranges to ~~avoid increases in hitrate and workload they would otherwise not properly manage~~.		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.

	~~====Priority Ranges====~~		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.
	~~Static~~ ranges ~~are further divided into four priority levels (P1~~, P2, ~~P3, P4)~~. ~~The network~~ will ~~first attempt~~ to ~~request a file from a~~ P1 ~~client, and then fall back to clients with a lower priority (P2 > P3 > P4) should the initial client(s) fail to serve the file~~.

	~~To receive the most P1 ranges, the client must maintain a high tested speed, [[quality]] value, and total static range count.~~ 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 [[Hentai@Home#Trust\|trust]], [[quality]], current/previous session runtime, or tested speed requirements.

	~~Furthermore, a client will be disqualified for any P1 range assignment should~~ they fail the minimum [[Hentai@Home#Trust\|trust]], [[quality]], current/previous session runtime, or tested speed requirements.

	====High-Capacity Ranges====		====High-Capacity Ranges====
Line 188:		Line 180:
	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 range]]s, as well as the allocation of traffic.		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 range]]s, 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 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.		*New clients with minimal traffic may experience some fluctuations in the value, but this will stabilize over time.

	~~{\|class=wikitable~~
	~~!Quality~~
	~~!Notes~~
	\|-
	~~\|10,000 \|\| Maximum quality.~~
	\|-
	~~\|8,000 \|\| [[Static Range]] cap becomes 6,000.~~
	\|-
	~~\|6,000 \|\| [[Static Range]] cap becomes 4,000.~~
	\|-
	~~\|3,000 \|\| [[Static Range]] cap becomes 1,000.~~
	\|-
	~~\|2,000 \|\| When below this value, the client will stay idle and will '''not''' receive any [[Hath]].~~
	\|-
	~~\|1,500 \|\| Starting point for new clients or those that have been unused for several days.~~
	\|}

	==[[Rewards]]==		==[[Rewards]]==
Line 211:		Line 187:

	The daily [[Hath]] earned per client is based on the following formula:		The daily [[Hath]] earned per client is based on the following formula:
	<pre<includeonly></includeonly> style="overflow: auto;{{{style\|}}}">'''Hathrate/day''' = 1 + 0.15 * max(hits_per_minute, KB_served_per_minute / 420) + 0.01 * ~~static_ranges~~</pre>		<pre<includeonly></includeonly> style="overflow: auto;{{{style\|}}}">'''Hathrate/day''' = 1 + 0.15 * max(hits_per_minute, KB_served_per_minute / 420) + 0.025 * active_rangecount + 0.05 * hicap_rangecount</pre>
	*~~Note that <tt>static_range</tt>~~ is capped by the client's tested speed. The cap is set at <tt>tested_speed/~~5 (in KB/s)</tt>. Example: For a client with 6000 static ranges assigned, but only 10000~~ KB/s ~~tested speed, its <tt>static_range~~</tt> ~~for Hathrate purposes will only be at 2000~~.		*The contribution from assigned ranges is capped by the client's tested speed. The cap is set to <tt>tested_speed / 100 KB/s</tt>.
	*The [[Hath]] is made available roughly every 4 hours the client has been running.		*The [[Hath]] is made available roughly every 4 hours the client has been running.
	*Only [[Hentai@Home#healthy\|healthy]] clients which current or previous session '''lasted for at least 24 hours straight''' will generate [[Hath]].		*Only [[Hentai@Home#healthy\|healthy]] clients which current or previous session '''lasted for at least 24 hours straight''' will generate [[Hath]].

Strongarm: /* High-Capacity Ranges */ 5TB

2024-01-05T17:05:17Z

High-Capacity Ranges: 5TB

← Older revision		Revision as of 17:05, 5 January 2024
Line 174:		Line 174:
	*Must have at least 100 GB of disk space assigned		*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. <span style="color:#ff0000">'''You will lose all of your assigned HC ranges if you set a [[Hentai@Home#Data_Transfer_Cap \| data transfer cap]] below ~~10000~~ GB/month or reduce the maximum upload rate below 10000 KB/s.'''</span> The traffic estimates for calculating Hathrate will also be reset.		The maximum number of HC ranges that a client can have is limited to 1 per 1 GiB of reserved disk space. <span style="color:#ff0000">'''You will lose all of your assigned HC ranges if you set a [[Hentai@Home#Data_Transfer_Cap \| data transfer cap]] below 5000 GB/month or reduce the maximum upload rate below 10000 KB/s.'''</span> 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.		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.

Strongarm: /* Data Transfer Cap */ Now H@H page says "5 TB/month"

2024-01-05T17:02:41Z

Data Transfer Cap: Now H@H page says "5 TB/month"

← Older revision		Revision as of 17:02, 5 January 2024
Line 94:		Line 94:
	*The value must be at least 1000 GB if set.		*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 a limit is set, '''the [[static range]] allocation of that client will be limited to 1 per 5 GB.'''
	**<span style="color:#ff0000">'''If set below ~~10000~~ GB/month, the client will not be assigned any [[Hentai@Home#High-Capacity_Ranges\|high-capacity ranges]], and all previously assigned high-capacity ranges will be removed ''immediately''.'''</span>		**<span style="color:#ff0000">'''If set below 5000 GB/month, the client will not be assigned any [[Hentai@Home#High-Capacity_Ranges\|high-capacity ranges]], and all previously assigned high-capacity ranges will be removed ''immediately''.'''</span>

	==Software==		==Software==

Nasu: /* Priority Ranges */

2023-12-19T17:26:09Z

Priority Ranges

← Older revision		Revision as of 17:26, 19 December 2023
Line 159:		Line 159:

	====Priority Ranges====		====Priority Ranges====
	Static ranges are further divided into ~~five~~ priority levels (P1, P2, P3, P4). The network will first attempt to request a file from a P1 client, and then fall back to clients with a lower priority (P2 > P3 > P4) should the initial client(s) fail to serve the file.		Static ranges are further divided into four priority levels (P1, P2, P3, P4). The network will first attempt to request a file from a P1 client, and then fall back to clients with a lower priority (P2 > P3 > P4) should the initial client(s) fail to serve the file.

	To receive the most P1 ranges, the client must maintain a high tested speed, [[quality]] value, and total static range count. Clients that experienced recent overloads will be less likely to be assigned with P1 ranges.		To receive the most P1 ranges, the client must maintain a high tested speed, [[quality]] value, and total static range count. Clients that experienced recent overloads will be less likely to be assigned with P1 ranges.

Kagoraphobia: /* Cache */

2023-12-19T15:24:33Z

Cache

← Older revision		Revision as of 15:24, 19 December 2023
Line 159:		Line 159:

	====Priority Ranges====		====Priority Ranges====
	Static ranges are further divided into five priority levels (P1, P2, P3, P4~~, P5~~). The network will first attempt to request a file from a P1 client, and then fall back to clients with a lower priority (P2 > P3 > P4 ~~> P5~~) should the initial client(s) fail to serve the file.		Static ranges are further divided into five priority levels (P1, P2, P3, P4). The network will first attempt to request a file from a P1 client, and then fall back to clients with a lower priority (P2 > P3 > P4) should the initial client(s) fail to serve the file.

	To receive the most P1 ranges, the client must maintain a high tested speed, [[quality]] value, and total static range count. Clients that experienced recent overloads will be less likely to be assigned with P1 ranges.		To receive the most P1 ranges, the client must maintain a high tested speed, [[quality]] value, and total static range count. Clients that experienced recent overloads will be less likely to be assigned with P1 ranges.

Tenboro: /* Minimum Requirements For New Clients */

2023-11-07T08:08:37Z

Minimum Requirements For New Clients

← Older revision		Revision as of 08:08, 7 November 2023
Line 20:		Line 20:
	\|[https://www.java.com/en/download/ Java Runtime Environment]		\|[https://www.java.com/en/download/ Java Runtime Environment]
	\|		\|
	*Version ~~must be~~ 8~~-11.~~		*Version 8 or newer
	*The JDKs are also usable.		*The JDKs are also usable.
	\|-		\|-

Kagoraphobia: /* High-Capacity Ranges */

2023-11-02T12:27:27Z

High-Capacity Ranges

← Older revision		Revision as of 12:27, 2 November 2023
Line 174:		Line 174:
	*Must have at least 100 GB of disk space assigned		*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. <span style="color:#ff0000">'''You will lose all of your assigned HC ranges if you set a [[Hentai@Home#Data_Transfer_Cap \| data transfer cap]] below 10000 GB/month or reduce the maximum upload rate below 10000 KB/s.'''</span> The traffic estimates for calculating ~~hathrate~~ will also be reset.		The maximum number of HC ranges that a client can have is limited to 1 per 1 GiB of reserved disk space. <span style="color:#ff0000">'''You will lose all of your assigned HC ranges if you set a [[Hentai@Home#Data_Transfer_Cap \| data transfer cap]] below 10000 GB/month or reduce the maximum upload rate below 10000 KB/s.'''</span> 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.		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.