但是有很多时候，我们会发现搜索中文所命名的资源的时候结果往往很少，这和搜索的原理有关。中文的组成方式不像英文等字母语言那样，是用空格隔开的一个个单词，所以例如那些我们熟知的网页搜索引擎在索引中文网页时，都需要对内容进行分词处理，中文分词技术属于自然语言处理技术范畴，也是一个非常复杂的研究领域，这已经不是目前常用的eD2k服务器端软件所能处理的。

电驴服务器搜索原理

现在我们来看目前最常用的电驴服务器（eDonkey server）端软件lugdunum eServer处理eD2k搜索的原理，由于电驴官方服务器端dServer年代久远，并且已经没有再被使用所以不再讨论。

eServer在处理搜索的时候有两种形式：关键词搜索和字符串搜索。

• 关键词搜索（keyword search）：即在文件名中寻找包含了此单词的文件，比如一个单词，“emule”，将会查找所有包含用分隔符所分割出来的独立单词“emule”的文件。
• 字符串搜索（substring search）：准确说是子字符串匹配，将会对文件名进行扫描，找出所有文件名中包含了所给字符串的文件，而不在乎是否是一个独立的单词，后面将说明。

现在我们来看eServer处理搜索时候所规定的特殊符号：

• 分隔符：空格 . < > { } [ ] - _ 等一些特殊字符，他们都被电驴服务器当作关键词的分隔符进行处理，但是也有例外情况比如版本号，像"1.2.3"，将会被视为一个完整的关键词。此外如果你需要强制搜索这些特殊字符则必须使用半角双引号""来进行转义。
• 起始符（开始符）：^ 起始符表示文件名称的开始，比如搜索“^emule”，我们会得到所有以“emule”为文件名开头的文件，例如“emule0.50a.zip”，而不会得到“[soft]emule0.50a.zip”这样的文件。
• 通配符（万用字元）：* 通配符用来代替任意个字符，可以是0个，1个或者多个，进行模糊的查找。值得说明的是电驴服务器不会在意*号的位置是在开头还是结尾，如果使用“*emule”或“emule*”来搜索，电驴服务器将会进行字符串搜索，将会扫描所有文件名中包含“emule”部分的文件，例如“kemule.zip”，“emulek.zip”等。

搜索中文命名文件

所以我们知道了，如果我们搜索“阿凡提”，那么我们只能搜索到那些文件名中使用了分隔符把“阿凡提”三个字分割成一个关键词的文件，比如：“[阿凡提.偷东西的驴].XviD.avi”这样的文件，我们无法找到文件名包含了诸如“聪明的阿凡提”或是“阿凡提的故事”这样的文件。这就是为什么很多人认为eD2k搜索中文不好用的原因。

找到原因了解决办法就很简单，

• 一种方法是多用几种常见的名称叫法来搜索，比如分别使用“阿凡提”，“聪明的阿凡提”，“阿凡提的故事”来搜索三次。
• 二是可以让电驴服务器来进行一次字符串搜索，我们可以加上通配符，比如搜索“*阿凡提”，这时候，eServer就会开始逐个寻找那些文件名里包含了“阿凡提”三个字的文件，好了，现在看看这次是不是搜索结果变多了！

此方法适合于所有使用了非单词组成的语言，中文，日文等命名的文件。

最后特别需要提醒的是进行字符串搜索会极大消耗电驴服务器的资源，而且会比进行关键词搜索慢很多，而且电驴服务器会在未完成搜索达到一定阈值的时候取消这次搜索，所以在可能的情况下，请尽量使用关键词搜索方式，而不要使用通配符，对于资源发布者来说，请尽量在文件命名时候使用分隔符突出资源名称的关键词，这样也能够方便大家。

本文参考了
lugdunummaster在eMule官方论坛讨论主题Light On Searching中的回帖。
台湾网友badcat在eMule EastShare官方论坛的主题帖[教學]eMule 的萬用字元搜尋 「*」方便多國語系搜尋 (2007-11-08 修)。

原文在：善用特殊符号搜索电驴网络中文资源
文章与图片版权遵循署名-非商业性使用-相同方式共享 3.0协议 BY-NC-SA，转载请署名作者和来源。

eMule 0.50a版开始提供了一个新的eD2k链接格式：ed2k://|search|[searchterm]|/ 这是一个用于搜索的链接格式，由searh标示和searchterm(搜索表达式)组成，这样就可以方便在一些特殊情况下发布搜索链接，但是碰上仅发布关键词的资源，还是需要手动切换到eMule进行搜索。没关系，eMule官方论坛的大牛们早就给我们想好了。

Opera添加eMule划词搜索项

转载自eMule官方论坛：http://forum.emule-project.net/index.php?showtopic=149479
作者：tHeWiZaRdOfDoS 和 Avi3k

在opera浏览器中，可以非常容易的添加一个在eMule中搜索的搜索项。
打开”首选项”，切换到”搜索”页，点击”添加”按钮并展开”细节>>”，添加以下参数

名称: 电骡搜索 （或其他你需要的，比如”search in eMule”）
关键字: e （或其他你需要的）
地址（支持单个关键词搜索，故建议使用下面的javascript方式代替）: ed2k://|search|%s|/
支持多个关键词搜索方法：多个关键词中间会被opera自动添加上”+”号，Avi3K为我们找到了解决方案，请使用下面的代码替换上面的地址
javascript:location.href=’ed2k://|search|’+'%s’.replace(/\x2B/g,’\x2520′)+’|/’;

点确定，添加完毕。
然后你既可以在opera的搜索框里搜索，更方便的是，以后你就可以选中一些文字，然后通过右键的搜索菜单在你的eMule里搜索该关键词。

Firefox添加eMule划词搜索项

安装一个firefox的emule搜索插件即可： http://forum.emule-project.net/index.php?showtopic=149369
作者：starko
Emulesearch Firefox Add-On

Internet Explorer添加eMule划词搜索项

安装一个IE的emule搜索插件即可： http://forum.emule-project.net/index.php?showtopic=149417
作者：Konstantin Staojitski
eMuleSearchIE插件
eMuleSearchIE插件以及源代码包（可手动安装）

其他用户脚本

关于其他的用户脚本（userscript，用于Google Chrome、Firefox的Greasemonkey等）、bookmarklet、Firegestures手势、Ubiquity脚本等，参见《一些eMule搜索的用户脚本（针对eM0.50a+）》。

收藏集的特点

收藏集本身不包含文件，只是一个链接的集合，所以很小巧，易于传播、交流。

对于普通使用者来说，收藏集下载时可更灵活地选择文件，也可作为一种文件管理方式。

对于发布者，收藏集是一种优雅、高效的发布形式，尤其当共享的文件数目较大时。

Howto: 创建一个收藏集

制作一个收藏集是很容易的，你只需在共享文件列表中选择好相应文件后，右键调出快捷菜单，选择相应菜单，如图所示：

随后进入创建收藏集的对话框，如下图所示：

如果钩选高级选项中的以简单文本方式保存，则收藏集会以纯文本形式保存，每一行是一个文件的eD2k链接，这可以让任何人都能获得文件的链接，但不支持注释等高级功能，这两个选项的更多讨论见参考部分。

点击保存即完成收藏集的创建，新创建的收藏集会被保存到“下载文件”设置的目录下

在短暂的hash后，你也应该可以在日之中看到它：

很多Mod里提供了专门的导航可以方便地查看共享文件中的所有收藏集。

改进的导航，于Xtreme 8.0

Howto: 使用收藏集

• 如果你是通过eMule下载的话，你可以在已完成的下载队列或共享文件列表中找到它；
• 将emulecollection关联到eMule主程序即可双击收藏集文件启动eMule并在eMule中打开该收藏集；
• 当然也可以把收藏集文件加入到你的eMule共享中来，在刷新共享文件列表后，你应该可以找到它了；
• 对于以简单文本方式保存的收藏集，你还可以用任何文本编辑器打开。

在eMule中找到收藏集后，你可以双击直接打开或者右键调出快捷菜单进行如查看，修改等操作。下图展示了一个打开的收藏集：

双击一个文件可以直接加入到下载队列中，也可以点击下载将选中的文件加入到下载队列中，勾选设置中的添加新下载到分类可以建立新的分类并把选中的文件加入其中，如果文件比较多的话这也许是个不错的选择。

右键点击文件可以看到该文件的详细资料：

该特性需要打开扩展设置中的“显示更多控制”

进阶说明

收藏集是在eMule 0.46b中引入的功能，只有0.46b以上版本支持收藏集。

命名的限制

在Windows下，以下符号因不能出现在的文件名中，会被忽略。

\ / : ? * "  < > |

简单文本保存和用户名认证标记两个选项

• 这两个选项不能同时选择；
• 简单文本保存的收藏集其内容完全由可读文本构成，其内容就是相应文件的ed2k链接明文；而正常保存的话，文件是特殊编码的，不可直接阅读，直接修改其内容很可能导致eMule不能打开该收藏集；
• 简单文本形式不支持制作者认证，且不能包含注释和评分信息；
• 对收藏集进行认证并不会限制他人对收藏集的内容进行修改，但修改后的收藏集不再有原制作者的身份标记，即制作者的认证码是不可仿冒的。

致谢

本文发布之初得到了ieD2k论坛的vyretop和纳兰旺财的指正，在此表示感谢。

更新

不出意外应该是最终版了，重写，之前版本中的一些认识错误修正了。

第1步、用光盘修复软件尝试尽量读出可用数据。
本人试用的是AnyReader。这款软件绕过Windows直接操作底层，按照自定义的次数不断尝试读取光盘，如果实在读取不成功，会以全0填充。其它的光盘修复软件应该大同小异。



推荐参数：重试次数3（太多也没什么意义），延时50ms，块大小475扇区。(475*2kB=950kB，是9500kB的整数分之一。mFR好像不支持导入AICH hashset，因此应当不可按片大小恢复。)
经过很短或很长的读取过程后，得到的文件情况如下所示：

注意：此方法仅适用于受损轻微的光盘。如果光盘受损严重，那么修复软件读取光盘的时间可能远远超过重新下载整个文件的时间。请自行斟酌。

第2步、获取该文件的hashset。
在eMule中搜索并重新下载该文件，一定要搜索*同一个*文件。如果曾经下载过这个文件，也可以从下载历史中查找并重新下载。如果右键菜单中没有选项，可将其链接拷贝到剪贴板，然后直接下载。

当进度条的所有部分变成或深或浅的蓝色，或者从文件详情中查看hashset显示可用的时候，暂停。

从文件详情查看此文件对应的part文件，记下来。

第3步、用metFileRegenerator修复文件，生成新的met文件
首先将通过AnyReader或其他光盘修复软件所生成的文件更名为刚才记录的.part文件，移动到某个指定的目录下。随后将eMule临时文件目录中对应的.part.met文件也拷贝到同一目录下。
选择修复

选择指定路径

选择part文件

开始修复，MFR会根据.part.met文件中已知的hashset校验part文件，并重新生成带有区块状态的新.part.met文件

第4步、导入eMule并下载剩余的部分
取消之前已经开始的下载（它已经完成了历史使命）……
从“工具”=>“导入”来导入新匹配的.part以及.part.met文件

现在就可以继续下载完成了。

在eMule的配置文件夹（也就是config目录下），新建一个名叫“PreviewApps.dat”的文件，使用文本编辑器比如记事本打开，然后按照如下格式输入：

程序名="程序的可执行文件路径及其运行参数"
（可以不带双引号，但是建议带上，否则路径中如果有空格将不能识别）

例如（仅仅是举例，请按照自己的实际情况处理）：
MediaPlayerClassic="C:\Program Files\mediaplayerclassic\mpc.exe"
IrfanView="C:\Program Files\irfanview\i_view32.exe"
Foobar2000="C:\Program Files\foobar2000\foobar2000.exe"
7-Zip="C:\Program Files\7-Zip\7zFM.exe"

保存即可，即时生效，现在转到你的eMule程序中，选中一个下载中的文件，右键-“预览”，看看是不是增加了新的预览选项，这样就不用再自己手动来打开part文件进行预览了。

eMule中调用外部程序预览下载中的文件

另外，如果你想使用eMule的增强的预览算法，你需要打开eMule的配置文件preferences.ini，然后找到“[eMule]”部分并在其下添加一行参数，
PreviewSmallBlocks=1
在保存preferences.ini文件时候，请确保eMule没有运行！

原文在：在eMule中调用外部程序进行预览，作者：uralhan
文章与图片版权遵循署名-非商业性使用-相同方式共享 3.0协议 BY-NC-SA，转载请署名来源。

如果某人允许你查看他的共享，而恰恰他的共享文件里有视频文件，那么我们除了从该视频文件所显示的参数如：长度、比特率、编码器等来了解该文件的质量以外，还可以通过eMule的视频截图功能（快照功能）来预览这个文件。这个功能会截取一个视频文件的4张快照，这样我们就可以对该视频文件进行更加直观的了解，以免下载自己并不想要的文件。

举例说明：
1.我们先找一个用户或者好友，右键选中“查看共享文件”，我就在好友列表里面抓一个吧。

eMule查看他人的共享

2.当他发送完他的共享文件列表以后，我们就可以在搜索栏目里面看到他全部共享的资源了。选择一个视频文件，然后右键选中“预览”，其他类型的文件没有此选项。

eMule的视频预览功能

3.等待一会儿，eMule就可以获取到该视频的4张快照了，这下再不怕下错了吧。:)

eMule获取4张视频截图

原文在：eMule查看别人共享的视频如何截图预览
文章与图片版权遵循署名-非商业性使用-相同方式共享 3.0协议 BY-NC-SA，转载请署名来源。

一.知道资源hash值如何搜索文件

表达式：
ed2k::文件哈希值

举例，我知道一个文件的hash值是：E8C636D0C0486378BF61E6A3000D0FB7
我就可以在选择搜索方式“服务器”或者“全局服务器”，然后输入：
ed2k::E8C636D0C0486378BF61E6A3000D0FB7

这样就能找到hash值等于这个值的文件了，如果文件名有很多种，可以点开文件名前面的小加号“+”，查看所有文件名。
如图所示：

已知文件hash搜索一个文件

二.寻找相关文件

表达式：
related::文件哈希值

同上选择搜索方式“服务器”或者“全局服务器”，然后输入：
related::E8C636D0C0486378BF61E6A3000D0FB7
就可以找到与此文件相关的文件，但是具体怎么相关，我暂时不知道，如果你知道请告诉我。谢谢！

原文在：知道hash值如何搜索文件
文章与图片版权遵循署名-非商业性使用-相同方式共享 3.0协议 BY-NC-SA，转载请署名来源。

正确的设置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。首发中国驴论坛。

介绍

KAD网络是eMule连接的网络之一。增加KAD节点数，是增加来源、提高eMule下载/上传速度的手段之一。

下载/上传某个公共的断头档时，会联系同样也在上传/下载此文件的用户，获取KAD节点列表，以达到增加KAD来源数的目的，从而增加你所能搜索到的文件数，并有可能增加下载/上传其他文件的速度。下载此断头档的用户越多，获取的KAD节点就越多。

制作KAD断头档，一般以正好9.28MB（9728001字节）为宜。因为断头档必须至少一整个文件段（文件段，又名文件块、区块，英文：partfile或chunk。eMule将文件分成每9.28MB一个文件段来下载，正好9.28MB的整数倍的时候，多余的0字节依然独立成为一个文件段），否则不会出现在共享列表中。所以，9.28MB是满足要求的最小大小。

在使用时另外还需要注意，一般应禁用A4AF。A4AF就是Ask for another file，如果对方源内有你需要下载的2个以上文件，eMule只为其中一个文件排队。禁用A4AF是因为，你将有可能只为断头档排队，导致其他正常下载的文件都靠边站。

在最早的时候，断头档并非为了获取KAD节点，而仅仅是为了找好友方便而设置的。由于eMule的好友功能不很完善，有用户想出了办法，几个好友下载一个断头档，联系好友时，从下载/上传断头档的名单中找到好友。至今也依然可以用断头档的方法联系好友。

使用

点击eD2k链接，下载某个断头档。

由于断头档是没有分发完便撤源的文件，下载断头档的用户将会永远无法完成它的下载。下载到一定大小之后，将会因为无来源而停止下载。但是它会一直存在于你的下载列表里，不要管它，不要删除，放在那里即可。

另外要把这些文件的优先级设为低。如果你用的是eMule，建议在“设置”的“扩展设置”中勾选“为节省CPU资源禁用A4F4”。

缺点

eMule可以通过自动更新KAD节点文件nodes.dat来获取KAD节点。通过断头档来获取节点，虽然可能容易找到“志同道合”的，但这样通过请求文件辗转获取，也会耗掉很多内存和网络带宽。

网友Felix Yan也认为，KAD断头档必须慎用。它“获得的许多节点是‘不优化’的，对下载现有资源和搜索需要的相关资源是没有任何帮助的。KAD本身是一个依据‘节点相关性’自动优化的系统，一个ID能连接到的节点永远只是偌大网络中很小的一部分。下载文件=>向KAD搜索、直到找到需要的源，这是一个自动优化的过程，使用“断头档”进行干预，是一种得不偿失的行为。”

一些断头档

这里是在网络上流传的一些断头档：

流传已久的三个断头档
ed2k: Cyndi-Connect.tmp
ed2k: [PTT]emule_friend.rar
ed2k: [ShareGet]emule_friend.rar
ied2k网友yanyuelin制作的断头档
ed2k: [ieD2k]好友档
ed2k: [ieD2k][kad][游戏]
ed2k: [ieD2k][kad][音乐]
ed2k: [ieD2k][kad][软件_资料_综艺_电视节目]
ed2k: [ieD2k][kad][剧集]
ed2k: [ieD2k][kad][动漫]
ed2k: [ieD2k][kad][电影]
教育网内流传的断头档
ed2k: 教育网的驴友请下载，以方便分享.rar

（如果你有其他好的断头档，可以在评论中告知）

参考与引用的文章

• 自食其力，增加eMule文件来源 --- Kad种子档 by chengr28
• KAD断头档分类，使连接KAD好友更加精确 by 夏夜晨星
• 使用电骡KAD，请慎用“断头档” by Felix Yan
• Kad因應黑暗冬天降臨，TWed2k建立如同辛蒂的好友名單 by skitter on TWed2k，需登录。eastshare上的转帖
• 断头档 by 百度百科

大家都知道，MorphXT在国外是仅次于官方版最常见的eMule Mod之一，由于其在反吸血环节比较薄弱，因此在国内很难推广。MorphXT本身是具有String list检测的，但是这不足以帮助我们阻挡凶恶的吸血鬼。Stulle在接手成为MorphXT的开发组组长后，为MorphXT增加了一些新的特性来对抗吸血行为，但是这仍然不够。因为MorphXT定位让其难以拥有如像DLP那样的反吸血利器。于是一些喜欢MorphXT的朋友们，开发出一些基于MorphXT的Mod，增强了其反吸血特性。比如支持Argos反吸血系统和DLP反吸血系统的MagicAngel。但是这个作者现在失踪了，其新版MA 3.8一直处于Alpha 2版本状态，无人管理。所以我当时把所有的注意力全部集中到StulleMule的身上。然而StulleMule果然没有辜负我的期望。其华丽的反吸血系统让我大开眼界：

首先，作为MorphXT后裔，其拥有父辈MorphXT的Failed download Ban（filter clients with failed downloads）系统。这个系统就是Stulle从Xtreme引入到MorphXT中的。Stulle的解释是，采用这种系统原因：有些客户端（尤其提到是在中国），假装像我们上传，但是每次上传的数量不超过12k。当该客户端第三次这样做时，将要被Ban掉。（原帖参见这里）
Failed download Ban的特点，让它成为一把双刃剑。一方面，它可以封杀一定的吸血行为，比如：只看重下行，不看重上行，把上传调到最低这种行为。或是诸如某些吸血端，走走停停地假装式的上传；另一方面，本来并不是不想上传，只是因为网络阻塞问题无法上传的时候，可能造成误伤。
这种封杀其实主要针对的是人的主观吸血行为，但是由于很多人的注意力全部在DLP那边，因此很可能忽视了这种封杀形式。因此并没有对那些限制上传的吸血者造成威慑力。

第二，DLP methods。顾名思义，这是使用了DLP的方法来封杀吸血客户端。StulleMule内置了v37的DLP列表，采用DLP方法来封杀客户端。但是其日志，比Xtreme更加详细。另外中文用户也无需担心看不懂反吸血日志了，因为这一部分在中文语言包中也一并被翻译出来了。

第三，Sivka Ban。知道Failed download Ban的人很少，知道这个的人就更少。这是Stulle从Sivka Mod中引入的封杀方式。（注：Sivka Mod确实是一种非常严格的Mod，我们知道非常严厉的Sivka积分，其实就是从这个Mod里首次出现，同时这个Mod有些对于吸血端，甚至是Low ID用户的一些限制设置，同时再加上这个封杀系统，虽然没有DLP但是其防御性也是非常的强大）。这个Ban的原理是监控反复请求的客户端，如果其请求的次数在一定时间内达到所设置好的数目，即认为其具有快速反复请求的攻击性行为而将其Ban掉。默认是在7分钟，检查数目为5次。这种封杀有效的对抗了某些恶意吸血端。这种吸血端有这样的行为：反复，快速请求资源，从而反复重新排队，以达到缩短队列的目的。同时这种封杀也能有效的遏制某些用户手动快速的，反复的请求资源，重新排队的行为。
反复，快速请求，本来就是一种恶意攻击行为，而在我国，某些用户听信了某些言论的误导（包括以前的我在内），在得不到下载量的同时，反复，快速地请求资源，认为这样会重新排队，并且缩短排队时间，变相插队。其实这种行为，本来就会受到服务器的监控，另一方面，如果有这类用户碰到了拥有这种封杀功能的客户端，很容易会被Ban掉。

以上，我粗浅地谈了一下StulleMule的反吸血系统，如果有什么错误，请指正。

图：Stulle Mule反吸血设置：

（作者Dantes Dream/Feathia原创）