Hentai@Home/Chinese

Hentai@Home (H@H)是一個開源的P2P圖庫分發系統，用於減輕E變態畫廊的負擔。當前最新的版本可以在更新發佈主題找到。

The client UI (maximized)

The client list UI

一般信息

H@H是一個可以比作SETI@home項目和BitTorrent之間交叉的項目。

所有參與的用戶都運行一個小型的基於Java的客戶端，從E變態的主要服務器下載文件到他們的電腦，並將這些文件傳遞給瀏覽E變態畫廊的人。這使E變態能夠使用較少的服務器帶寬提供更多的圖像。

客戶端可以在任何時間內自由運行，但建議儘可能長時間連續運行，以獲得最大回報。

報名

The H@H application form.

新客戶機的最低要求

要求	說明
Java運行時環境	必須爲8-11 需要同時安裝JDK
80+ Mbit/s的測量速度	至少有2000kB/s必須專門用於H@H 這同時適用於上傳和下載。
1000 GB/月的數據流量	用戶可以限制每月使用多少流量。注意：這個限制是近似的
10GB以上專用硬盤空間	固態硬盤是更理想的選擇; 無需擔心寫入耐久。 推薦每 0.2 Mbit/s 至少1GB，以實現最佳的靜態區間分配。 請確保客戶端能夠長期維持速度和磁盤I/O。
一個開放的TCP端口	推薦使用443端口，否則必須爲1024-65536之間的值 推薦使用未註冊的IANA端口或UNIX內核端口作爲內網端口。查看這個清單，看看是否有潛在的端口衝突。 有些端口是不允許的。
一個獨立的IPv4 IP地址	每個客戶機都應當有一個不同的靜態IPv4地址 （中文版特供：一些情況下，CG-NAT1也可以）
正常運行時間	每個客戶機在6個月內應該有75-80%的時間保持在線。宕機時間達到不可接受水平的客戶端會被撤銷。如果一個客戶端持續離綫超過3個月，它將會被刪除且不可恢復。

獲取客戶端密鑰

註冊第一個客戶的用戶只需進入 "我的主頁 "中的Hentai@Home頁面進行申請。申請通常會在一天内處理。

對於任何額外的客戶機，請私信Tenboro。對於希望運行5個以上客戶機的用戶，其現有客戶機的平均穩定質量必須達到7,000以上才能分配更多的鑰匙。

安裝指南

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

限制

一個客戶的最大爆發速度（以KB/s爲單位）將決定可以同時擁有的最大連接數（在4800KB/s或更高的速度下，最多500個）。

同時連接是由客戶的點擊率和爆發速度決定的（在速度測試期間，數據包的大小被調整爲與客戶的爆發速度相匹配）。

最大連接數 (上限 500) = 20 + 最大爆發速度 / 10000

磁盤緩存大小（以GB爲單位）必須足以維持靜態區間。客戶端必須能夠在任何時候有10GB空間，或者爲每個靜態區間提供250MB，以較高者爲準。

最小緩存大小 = max(10, 靜態區間數量 * 250 / 1024)

速度測試

當H@H客戶端啓動時，它與一個H@H控制服務器聯繫，該服務器測試客戶端的連接，以檢查它是否能以配置的最大爆發速度上傳數據。如果不能，最大爆發速度會在內部降低到測量的上傳速度，以防止連接過載。

活動

如果一個客戶端符合以下全部要求，那麽它將被認爲是“健康”的：

• 客戶端需要處於運行狀態，而不是暫挂
• 客戶端的信任度必須高於0
• 客戶端的質量必須維持在2000以上
• 客戶端的測速結果必須高於400KB/s（對亞洲區域）或者高於800KB/s（對其他區域）

如果不符合上述的任意一個，客戶端將在網絡中處於閑置狀態，直到它能滿足上述要求。

數據傳輸上限

你可以在客戶端設置頁面，給每個客戶端定義每月數據傳輸上限（在Advanced Settings部分）。這有助於防止H@H使用超過ISP設定的每月數據量上限。

• 如果系統偵測到即將超過限制，它將減少你客戶端上的緩存塊的優先級來減少負載，但這個措施不能保證數據傳輸量低於這個限制
• 如果使用這個設置，必須至少設置為1000GB/月
• 如果使用這個設置，則每5GB/月將為客戶端增加1靜態區間數量上限
  • 如果設置了低於5000GB/月的數值, 客戶端將不會被分配到任何高容量區間, 并且之前分配的所有高容量區間將被立刻移除.

軟件

有幾個命令行開關可以給H@H應用程序，以改變它的一些行爲。

--disable_bwm

(也可以從客戶的設置頁面設置)

禁用帶寬監控，它可以防止客戶端使用超過 "最大爆發速度 "參數值的上傳速度。H@H調度器仍然會尊照 "最大爆發速度 "參數，這樣客戶端的平均上傳速度就不會超過這個值。然而，客戶端可能會使用其連接提供的儘可能多的上傳速度來發送文件，這通常會導致上傳峯值。

在某些情況下，帶寬監控器無法使用設定的全部最大上傳速度，這可能導致客戶端的上傳速度利用不足（並可能觸發錯誤的過載通知）。在這種情況下，最好禁用帶寬監控器，以使客戶端有更好的性能。

--disable_logging

(也可以從客戶的設置頁面設置)

禁用打開、創建和寫入log_out文件的功能。這將大大減少機械硬盤的讀取/寫入量，但使網絡故障排除更加困難。Java錯誤仍將被記錄到log_err。

--flush-logs

每寫一行就把日誌刷到磁盤上。這將增加讀取/寫入量；主要推薦在日誌被寫入內存虛擬硬盤時使用。

--max_connections=conn

設置應用程序可以處理的最大連接數爲conn。默認的最大連接數取決於最大爆發速度參數，詳見上文。在一些罕見的情況下，默認值太低，最大連接數需要稍微增加，以避免觸發錯誤的過載通知。把這個值設置得太高，可能會對客戶的性能產生嚴重的影響，並對整個H@H網絡產生嚴重的影響。除非你完全知道自己在做什麼，否則不要改變這個值。

--port

覆蓋客戶端的端口設置。例如，我們可以使用這個選項和下面的iptables規則來允許在一個正式的端口上運行H@H（在設置頁面），同時綁定或隧穿至一個完全不同的端口。這種情況很少發生，但一個例子是：在設置中把H@H配置爲在6000端口啓動，然後使用--port=7777和以下iptables規則。

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

--rescan-cache

檢查緩存中的錯誤。

--silentstart

在最小化模式/托盤圖標中啓動用戶界面。

--skip_free_space_check

禁用空閒空間檢查，這樣，如果包含緩存文件夾的分區上的剩餘空間小於配置的參數（如果該參數被設置爲小於100MB，則爲100MB），應用程序就不會出錯。

--verify_cache

(也可以從客戶的設置頁面設置)

強制對整個緩存進行檢查。這與--rescan-cache相同，只是每個文件的SHA-1哈希值也會被檢查；這可能需要很長的時間。

--disable-ip-origin-check

禁用RPC服務器請求來自白名單IP的要求。我們不鼓勵使用這種方式，因爲它降低了安全性，但可能允許客戶端在一些常見的非透明代理配置中工作。

--disable-flood-control

禁用每個IP地址的連接速率限制。可能需要與上述觸發器一起使用。

目錄命令

--cache-dir

--data-dir

--download-dir

--log-dir

--temp-dir

這些參數允許改變這些目錄的位置。如果路徑中存在空格，則需要引號。如果目錄不存在，H@H將嘗試創建該目錄。只有log和temp可以共享一個目錄。

比如：

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

緩存

系統只用靜態區間的文件來填充客戶的緩存。用戶不應該篡改任何這些文件；這將導致客戶端嚴重的信任度和緩存數據庫問題。如果需要，損壞的文件將被刪除，或者替換。

靜態區間

每一個靜態區間對應這個網站內容的65536分之一。伺服器會假定客戶端總是可以在不單獨跟蹤文件的情況下分發區間所對應的文件。如果一個區間所對應的文件尚未被緩存，那麽客戶端會根據需求從鏡像伺服器代理請求對應的文件並存儲以備後用。

一個特定地域内的靜態區間的分配基於一個評分算法。如果多個客戶端間其他因素（比如，測試速度）相似，它通常優先考慮新客戶端和區間較少的客戶端。如果一個靜態區間只分配給了少於預期數量的客戶端，或者低於平均值的客戶端，那麽這個區間將會再被分配給另一個可用的客戶端。

靜態區間被分割為不同的優先等級，其中P1、P2、P3為“活躍的”區間。網絡會首先嘗試從P1客戶端請求文件，然後再回落至其他更低優先級的客戶端，如果更高優先級的客戶端未能成功提供文件的話。 最低優先級的P4是為高級區間降級而分配的“不活躍”的區間。比如一個客戶端下綫了太長的時間。 為獲取盡可能多的P1區間，客戶端需要維持一個高的測試速率以及高質量值，並且在綫時間盡可能的長。近期發生過過載的客戶端將不太可能被分配P1區間。

如果客戶端的信用，當前/先前會話運行時間或者測速值未能保持在最低值以上，那麽它們就不能被分配更多區塊。

高容量區間

靜態區間也可以被升級爲高容量區間，這將使客戶端能提供該區間内的大型或者原始質量圖片。

客戶端需要滿足更嚴格的條件來獲取高容量區間：

• 必須處於三個共給盈餘的地域，即歐洲、北美、亞洲（不包含中國大陸）
• 必須設置至少10000KB/s的速度上限，並達到8000KB/s的測試速度
• 必須有至少10000GB/月的數據傳輸量上限，或者不設置上限
• 必須至少有100GB硬盤空間

每1GiB預留的磁盤空間將爲客戶端增加1高容量區間數量上限。當客戶端被設置低於5000GB/月的數據上傳量上限，或者低於10000KB/s的上傳速度上限時，將立刻失去所有的已分配高容量區間。用於計算hath收益的流量估計值也將被重置。

由於緩存容量過剩，擁有較低比例P1區間的客戶端更容易獲得高容量區間升級。不要爲了獲得高容量區間而嘗試避免獲得P1區間，因爲P1區間始終比高容量區間容易獲得。

注意，高容量區間是獨立的優先級，這意味著一個靜態區間可以同時為P1區間和高容量區間。

信任度

信任度描述此客戶機與其他客戶機相比的表現。

• 信任度的上限是+1000，如果客戶表現正常，即使不提供文件，也會以每分鐘1-4的速度逐漸上升。
• 負的信任值往往來自於不恰當的關閉、糟糕的連接，或有高於預期的緩存未命中數量。

質量

質量衡量客戶端的長期整體穩定性和可靠性，通過比較地域中客戶端的平均故障率和平均命中率。它影響靜態區間和區間優先級的分配，以及流量的分配。

• 如果一個客戶端的平均故障率和該地域平均水平一致，那麽它的質量為9000。低於該地域平均故障率一半的客戶端將獲得最高質量（10000）。
• 如果質量掉到2000以下，客戶端會停止接收流量，直到其質量恢復為止。
• 流量極小的新客戶端會遇到一些數值波動，但隨著時間推移，會趨於穩定。

獎勵

客戶端每被點擊一次，用戶就會獲得1個GP，並可以在H@H排行榜上競爭一個位置。在運行健康的H@H客戶端時，用戶還會獲得用於購買Hath Perks的Hath。

每個客戶每天獲得的金額是基於以下的公式：

每日Hath獲取率 = 1 + 0.15 * 最大值(每分鐘點擊量, 每分鐘服務的文件數量(KB) / 420) + 0.025 * 活躍區間數量 + 0.05 * 高容區間數量

• 注意：被分配的區間的數量受限于客戶端的測速數值。這個限制為 測速值 / 100 KB/s。
• 客戶端每運行大約4個小時，Hath就會生成一次。
• 只有今次和上一次的總運行時數至少為 24 小時的健康客戶端才會收到 Hath。
• 如果質量低於 2000，客戶將不會收到任何 Hath。

H@H 下載器

欲瞭解更多信息，請查看這個主題。

可以使用H@H客戶端來下載檔案（而不是通過HTTPS）。

• 分辨率選項包括780x、980x、1280x、1600x、2400x或原始分辨率（有些可能不可用）。
• 一旦載入隊列，就沒有辦法終止客戶端下載畫廊。
• 與檔案下載不同，完成下載之後會創建一個galleryinfo.txt 文件。
• 文件名的變更 依然會發生。
• 這些下載依然會花費GP/C (例外情況見下文).
• 下載隊列是服務器端的，因此不受客戶端中斷的影響。如果客戶端被重新啓動，它將恢復。隊列中的下載不會被修剪，除非客戶端在整整一週內都沒有下載它們。客戶端將驗證下載的文件在完成時是否有預期的Hath值。

免費的文檔下載配額

持續運行超過24小時的健康客戶端每天可以獲得1000MB的免費檔案下載配額。每個調整後的平均點擊量，可獲得額外的10MB/天。

• 這個配額是以7天的滑動窗口來衡量的。
• 重新創建的檔案不符合條件。
• 額外的客戶機不會再獲得1000MB。
• 用戶已經獲得的數量可以在他們的H@H客戶列表頁的 "你的活動客戶端 "部分的底部找到。

撤銷

如果客戶端顯著無法達到正常運行的要求，或者定時清除它的緩存/區間，那麽它會被撤銷。撤銷的客戶端無法再被使用，并且會在3個月的寬限期后被刪除。

根據撤銷的原因，被撤銷的客戶端有時可以重新激活。你需要有充分的理由，這將根據具體情況決定。“我沒有閲讀注冊頁面上的要求，也沒有收到多個自動警告”并不是一個好的理由。

如果你的客戶端被撤銷，你未來將不能重新申請H@H。

另見

• 常見問題 - Hentai@Home
• 技術問題 - H@H
• Hath
• 下載
• Renting A Seedbox

論壇鏈接

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