【原创】 eMule, 音乐下载与分享利器（使用指南与探讨） - 耳机网-耳机大家坛

下面是我的小小驴运行后在日志里显示的信息（可能和你的不同哟，肯定不同，呵呵）：

2003-12-8 17:51:26: 发现15个已知的共享文件
2003-12-8 17:51:26: Creditfile已加载，4522个客户已知，35 用户被删除（消失五个月）
2003-12-8 17:51:28: 连接断开
2003-12-8 17:51:29: 在server.met中找到55个服务器
2003-12-8 17:51:29: 发现1个.part文件
2003-12-8 17:51:29: eMule版本0.30d-ACAT已经就绪
2003-12-8 17:51:29: My UserHash: FA561B6E870E442DBC223918471C6F6F
2003-12-8 17:51:29: 正在连接
2003-12-8 17:51:30: 正在连接到61.172.245.120（61.172.245.120:4242）...
2003-12-8 17:51:30: 连接到61.172.245.120（61.172.245.120:4242），发送登陆请求
2003-12-8 17:51:32: 连接建立于：61.172.245.120
2003-12-8 17:51:32: 新的客户ID为3478929370

红色的就是本人小小驴的UserHash，新来的驴友可能对EM的UserHash比较陌生，下面我们来了解一下。其实简单解释一下你就会很清楚了。 UserHash就好比咱们现实生活中的身份证号码，每个人只有一个唯一的号码。同样，每个EM也就有一个唯一的UserHash。具体UserHash 用什么算法生成本人也不太清楚，感兴趣就自己找资料看去。总之，UserHash的生成很随机，基本不会和其他人的重复，重复的概率很小很小，和中500 万的概率差不多，呵呵。有的驴友电脑里开双驴或者多驴时喜欢把老驴直接复制过去，这会带来什么不好呢？就是UserHash相同了，这样当你开几个驴子同时下载张三用户的文件时，只会有一个驴子能通过安全认证而得到下载，其他驴子因为UserHash相同，无法通过安全认证，也就不能从张三这儿下载了。

2003-12-8 17:51:26: Creditfile已加载，4522个客户已知，35 用户被删除（消失五个月）

嗯，Creditfile已加载是什么意思？
EM的选项设置－扩展设置里可以设置启用信用系统－－Credit system（受益上传者），如果你启用了这个Credit system，那你的EM 5个月后就会出现客户被删除的信息。那这个信用系统（Credit system）是如何受益上传者的呢？这就是UserHash在起作用了。举个简单的例子，比如张三给李四上传了，那么李四就会记下张三的 UserHash，如果下次张三要下载李四的东西时，李四就会给张三的评分比普通的用户高（知恩图报嘛），这样张三在李四这儿就可以少排队或者不排队进入下载。当然，张三和李四建立的这种信用的评分关系只能持续5个月，如果5个月内两个用户都没有再建立过连接，就会出现上面的被删除的现象了。
另外，这也就是我们为何要加大上传原因，因为上传多了后给你带来的好处就是以后你下载东西时可以少排队或者不排队。所以，大家对自己的UserHash要加倍的珍惜，特别是上传量大的驴友，经常备份config下的文件是很有必要的。一旦UserHash变了，你和其他驴驴建立的这种信用关系也就没了。

最近又很多同学被EM和BT的不同缓存设定误解了，以为EM的缓存越大越好
为了减少这种误解，特开此帖科普一下

缓存分类
缓存主要有两大类，一类是缓存，英文一般是Cache、Buffer。这类缓存是由应用程序设定和管理的，所有文件公用的缓存，BT使用这种缓存。另一类是文件缓存，英文一般是File Buffer。这类缓存是由系统设定和管理的，每个文件都有自己专用的文件缓存，EM使用这类缓存。
Cache、 Buffer是由应用程序设定和管理的，它并不一定位于物理内存中。不过可以通过一个简单的测试知道它是否位于物理内存中。首先，将缓存大小设定为几M，运行一段时间，记录下程序占用的物理内存和虚拟内存大小。然后将缓存大小设定为刚才值得10倍，再运行一段时间，记录下程序占用的物理内存和虚拟内存大小。比较两次记录，看看是物理内存占用是否明显增大，明显的话，缓存位于物理内存之中。如果是虚拟内存占用明显增大，而物理内存变化不明显，那么这个应用程序的缓存并不位于物理内存之中。
File Buffer由于是系统设定和管理的，只要你的物理内存充足，一般都是位于物理内存中。又由于它是每个文件专用的，即使只设定了1M的File Buffer，你如果打开了30个文件，那么就是总共30M的File Buffer。后面介绍完原理后，你就应该知道这对绝大部分人已经足够了。

缓存工作原理
缓存（Cahce、Buffer）可以细分为读和写。读缓存（Read Buffer）作用是将文件内容预读到内存中，在读操作前检查文件是否在缓存中（术语是命中），没有命中的话，在从硬盘中读取文件。从上述工作原理可知，命中率读缓存的关键指标。
现在，我们分析命中率。命中率分顺序读取命中率和随机读取命中率。
从计算机的专业书籍中我们知道，CPU的高速缓存可以看作是物理内存的读缓存，两者的容量比一般是1：1000，然而CPU高速缓存的命中率一般不低于80%。因此我们知道，只需要很小的缓存就可以使得顺序读取的命中率很高。
而随机读取的命中率，用概率论算算就知道，1G的内容需要800M的缓存才能达到80%的命中率。需要极大的缓存才能做到较高的命中率。
在实际中，顺序读取的发生频率比随机读写要多少几个数量级，因此用更好的缓存算法提高顺序读取的命中率才是读缓存的前进方向，单纯提升缓存大小没有太大意义。
综合上面的分析我们知道，提高读缓存的效果并不需要很大的缓存，即使设置了很大的缓存，也是在浪费你的物理内存。
写缓存（Write Buffer）的作用是在写入文件之前，先将要写入的内容写到内存中，积累到一定的量以后，再写入实际文件。因此，写缓存没有命中率的说法，它的效果只和写入速度和缓存大小有关。

文件缓存（File Buffer）是由系统设置和管理的，每打开一个文件，系统会自动给那个文件分配File Buffer，一般不分读写。虽然说Windows很垃圾，但是它的File Buffer算法不比一般软件差，所以关键是设置多大比较好而已。但是，如果File Buffer设置过大，例如30M，你往里面写了10M的数据，系统很可能认为缓存还很空，并不进行实际写入操作。万一在这时断电或者程序崩溃，你这 10M就会丢失了。

BT缓存的大小
缓存的大小自然和读写速度相关，在这里我把普通带宽、小水管定义为2MADSL，U/D=64K/256K；高带宽、大水管定义为U/D=1M/2M
对于小水管来说，8M的写缓存（Write Buffer）需要半分钟才能填满，平均来说大概10S~15S写一次硬盘，如果这个频率你都不能接受的话，那你还是用无盘工作站好了。
至于读缓存，BT的上传是按文件块进行的（一般的种子，文件块大小是256K/512K）。64K的上传槽（Slot）一般是4~6，上传槽速度（Slot Speed）一般不超过20K/S，一个文件块足够它传10S。因此，给每个Slot两个文件块的读缓存就差不多了，害怕命中率不够高，每个Slot四个文件块也应该够了。具体算一下，512K*6Slot*（2~4）=6~12M，也就是说6~12M的读缓存就足够了。
把读写缓存加起来，8+ 12=20M，对于小水管是足够多了。用UT，使用上述缓存大小设定，读缓存的命中率能达到85%+。至于200M的缓存，如BC之流，命中率可能可以提升，但是提升的很有限。而且，由于随机读取的客观存在，即使你有200M缓存，你也不可能保证命中，读硬盘的频率不会比20M缓存低多少。
对于大水管来说，想像小水管一样10~15S写一次硬盘是不可能的，而且BT下载完一个完整的文件块后，为了保证数据安全，会尽快将那个数据块写入硬盘。因此，对于大水管来说，设置10倍于下载速度的写缓存，满足3~5S写一次硬盘的要求就可以了，太大也没有意义。
大水管由于上传速度快，发生随机读取的可能性更高了，平均几秒钟就会发生一次不命中，必需读硬盘。因此，读缓存的量也不需要太多，缓存100个左右的文件块，也就是大约50M的缓存也就差不多了。
加起来大概需要70M的缓存，同样的，在这个情况下就算设置200M的缓存，读硬盘的频率也不见得低多少。

EM缓存的大小
前文已经说了，EM的缓存是针对文件的，如假设每个Slot对应一个文件，那么EM缓存大小时候合理关键看Slot Speed。
对于小水管，Slot Speed也是就是10多20K，512K的File Buffer足够它挥霍20S以上，足够了。
如果说你只下载少量文件，可能有多个Slot在写入同一文件，可能就需要1M的File Buffer。
对于大水管，Slot Speed上百，但这并不意味着需要10M以上的File Buffer。原因有两个，一个和BT一样，由于随机读取的存在，你必须读硬盘；另一个就是File Buffer越大，文件丢失的可能性越大，而且这个可能性是指数级增长的。因此，即使是大水管，1.5M~2M的File Buffer也差不多了。可以利用优先级的管理，让EM上传不同的文件，下载的文件数量也多一点，让每个Slot对应不同的文件。