eMule Fans 電騾愛好者

HideOS和SOTN是為了加速發布文件而開發的一些功能，這些功能的基本工作原理是盡量只上傳上傳量比較少的文件分塊。

正確的設置HideOS和SOTN是可以加速文件發布的進程的，但是如果不正確的設置這些功能，反正會拖慢文件發布的進程。

在講述這些功能的具體利弊得失之前，我覺得有必要說明下這些功能設計時的一些背景。

HideOS這類的功能都是建立在所有節點上傳能力都差不多這個假設上。這裡的上傳能力，不僅僅指上傳帶寬，還包括所有節點都有意願上傳你發布的文件，以及他不會在文件發布完成之前就下線了。

在這些前提下，我們分析下HideOS的性能。假設發布者以100k/s的上傳帶寬發布一個700M的文件，HideOS的閾值設置為1，即上傳一次文件塊後隱藏，直到下一輪上傳。

首先，這個文件大約2小時上傳一輪，也就是說每個文件塊每2小時有且僅有一次上傳機會。

接著我們假設所有接收到文件塊的人，以50k/s的上傳帶寬分流這個文件。通過很簡單的計算我們可以知道，在兩小時的時間中，每個文件塊都會被上傳 35~40次。

很明顯，這如上假設下，當所有文件塊都上傳一遍之後，就算有一部分人下線了，2小時之內這個文件至少會具有20+完整源，發布應該是成功完成了。

但是國內的網路情況支持這些假設嗎？很明顯，不支持。

國內網路的情況是兩極分化很嚴重。水管大的用戶數量很少，但是50k/s對他們來說小意思，不算數。一般ADSL小水管，用戶數量很大，但是能給em開 40K的上傳算不錯了，在這40k中，大部分都會用於上傳其他共享文件，即使是那些不怎麼共享文件的用戶，因為同時下載數往往有10+，能分給某個特定文件的平均上傳帶寬有2~3k/s就不錯了。

在這個情況下，我們重新分析一下上面的結論。如果文件塊傳給大水管了，那麼OK了，這個文件塊算是發布出去了。如果文件塊傳給小水管了，那麼麻煩了，2~3k/s的速度，在2小時的時間內大概能把這個文件塊上傳2次。嗯，沒錯，僅僅兩次，這還算是樂觀的。遇到一些只開20k/s總上傳的用戶，2小時內對應的文件塊可能連一次上傳都沒有。

這還不算是最糟糕的事情，真正糟糕的事情在這裡，國內用戶每次運行em的時間也就是4~5個小時(有國外的研究可以佐證)，也就是說當發布者將一個文件塊傳輸給某個小水管之後，某個小水管很可能在這個文件塊還沒有分流出去之前就關機睡覺了。於是，在這2個小時中，這個文件塊沒有得到有效的分流。

很顯然，發布者的噩夢就此產生。由於HideOS的極端設置，在我們的例子中發布者每2小時只能把一個文件塊上傳給一個用戶。如果說發布者運氣不好，某個文件塊給了一個很快就要下線的小水管(其實這個可能性還不低)，那麼這2個小時這個文件塊是無法分流了，他只能希望下一個2小時中他能把這個文件塊交給一個大水管。我們都知道越不希望發生的事情就越容易發生，下一個2小時中很可能又會把文件塊傳輸給不合適的用戶。1天也就24小時，可以嘗試12次，如果 12次都是把文件塊給到不合適的人，那麼這個文件被發布一整天之後依然沒有完整源。極端設置的HideOS在國內網路的實際情況下只能造就杯具。

其實要避免這種杯具也不難，理解HideOS的本意就好了。Hide Over Shared就是隱藏過度分享的文件塊，而不是分享之後立即隱藏。一個文件塊上傳了10次，另外一個才上傳了1次，那麼上傳10次這個肯定是Over Shared了，應該Hide。但是一個10次一個8次，你能說上傳10次那個Over Shared了么？我想應該不能吧。

此外，發布者的帶寬對HideOS的設置也有很大的影響。如果發布者有1M/s的帶寬上傳一個700M的文件，10多分鐘這個文件就可以完整分享一次。在這種情況下，HideOS已經基本失去意義，無論是否啟用這個功能，每個文件塊在20~30分鐘左右都會得到一次上傳。相反，在10k/s的帶寬上發布 700M的文件，需要整整一天才能把這個文件完整分享1次，HideOS就必須採取極端設置，把分享的希望寄托在其他節點身上。

綜上所述，只有小水管發布文件時才需要極端HideOS設置，分享1次或者2次文件塊之後立即隱藏。中等的水管可以適當設置 HideOS，當某個文件塊上傳的次數比其他文件塊多好幾次時才去隱藏，避免預覽或者邊下邊看的騷擾。特大號水管Hide不Hide無所謂了，HideOS、SOTN等等本來就不是為你們設計的功能，建議關閉。

作者zz_fly。首發中國驢論壇。