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。首发中国驴论坛 [1]。