eMule电驴eDonkey源代码精辟分析
电骡
学习emule知识必备网站:
/
http://www.emule-mods.de/?mods=start
emule是电骡,不是电驴,电驴是另外一个p2p软件,所有的资源都是大家自己共享在自家电脑里的,只要有人共享,你用emule就能搜索到(非verycd的网站搜索,也不是verycd版emule那种阉割搜索),根本就不存在一次性删除的问题,除非这个资源在地球上没有人再共享了。
电骡≠电驴≠verycd ,verycd只是个挂羊头卖狗肉的。
15、/
中国.电骡,臭名昭著的vagga。
16、/
这个不用说了,上海隐志网络科技有限公司建立的ed2k资源站,估计也是全球唯一获政府许可“合法运营盗版”的商业ed2k资源站。不过其基于emule开发的几个mod:verycd版和easymule版因为某些流氓行为而被称作“阉割驴”,也因为长期盗用“电驴官方”和“emule官方”称号而被广大电驴爱好者和电骡爱好者所诟病。强烈不推荐使用其客户端,并号召大家反对verycd的无耻行为!
2. /
一个新兴站点 QvoCD电驴,口号是“分享如此简单”,如果你厌倦了verycd的审核和商业铜臭,以及对资源发布者辛苦劳动的不尊重,试试这个网站。
3、/
原来vc的大佬吕大建的!纯洁的ed2k资源网。据说某臭名昭著的“假电驴”公司告密的缘故,ied2k已经被挡在了墙外,只能用代理访问网站,网站很久不更新了,管理员失踪!向ied2k致敬!
donkey : n. 驴子;倔脾气的人;傻瓜
mule : n. 骡子,马骡;固执的人;〈纺〉走锭精纺机
edoneky才是正宗的电驴,美国人发明。
emule是正宗的电骡,德国人制作!emule正宗官方: 和verycd没有半点关系。
电动车控制器C语言源代码讲解
******************************************************************************/
void main(void)
{
Init(); //初始化
Init_IO(); //初始化端口
H_Sample(); //霍尔信号采样
{
Speed_Buffer[i]=0;
}
for (i=0;i<16;i++)
{
Voltage_Buffer[i]=0;
}
Current_P=0;
Speed_P=0;
Voltage_P=0;;
Speed_SUM=0;
// PWM_MAX=0;
Current_SUM=0;
Voltage_SUM=0;
H_State=0;
KS_Finish();
}
}
//***Function Set***//
if(AH_Count >= 100)
{
AutoHelp(); //自助力
AH_Count = 0;
}
if(KS_CNT >= 3000)
{
KS_CNT = 0;
Keep_Speed(); //巡航定速
}
Volt_Low(); //欠压保护
*/
while(1)
{
_nop_();
//AutoHelpEN(0,0x1AA,100);
//Keep_SpeedEN(1,0x20,6);
//Current_Lim(0xB50);
//LowVoltage_Lim(0x9B0);
//EABS_Set(0,0);
电驴基础知识
界面各种图标说明正在传输数据或正在从当前客户端接收Hash信息正在排队,或正在向此客户端发出请求正在连接该客户端该客户端上没有需要的文件块, 正在请求另一个文件或因为是低ID所以以连接不上状态未知新信息普通电驴或早期的电骡客户端承认电骡扩展协议的客户端高信用客户端(这意味着它有更高的优先权)承认电骡扩展协议并拥有高信用值的客户端mlDonkey 客户端拥有高信用值的mlDonkey客户端eDonkey2000-Overnet-Hybrid 客户端拥有高信用值的eDonkey2000-Overnet-Hybrid 客户端Shareaza 客户端拥有高信用点数的Shareaza 客户端通过安全身份验证的客户端电骡服务器和Kad网络上是高ID电骡服务器是高ID和Kad网络上是低ID(防火墙状态)电骡服务器是低ID, Kad网络上是高ID电骡服务器和Kad网络上是低ID没连接Kad网络,电骡服务器是高ID没连接电骡服务器, Kad网络上是高ID没连接Kad网络, 电骡服务器是低ID,没连接电骡服务器, Kad网络上是低ID没连接Kad连接- 良好Kad连接- 回应失败过一次Kad连接- 很有可能断了,可能会被移除当连用高ID接上高服务器时的电骡托盘图标当连用低ID接上高服务器时的电骡托盘图标当没有连接上高服务器时的电骡托盘图标当前文件有一个正面的评价此文件带有伪文件,有坏块或无效标识进度条上的颜色说明在下载列表中的每个下载文件都有一条用来显示文件下载进程和文件块有效性的彩色条.(扁平风格)(圆滑风格)黑色表示这部分文件你已经下载了.红色表示在已找到的所有源上都没有这部分文件.不同深度的蓝色表示这部分文件在所有源上的有效性. 越深,这部分文件越多人拥有.黄色表示这部分文件正在被别人下载中.最上面的绿色条显示这个文件的下载总进度(扁平风格)(圆滑风格)一个完整的绿色条表示文件已经下载完成.(扁平风格)(圆滑风格)一个完整的深红色或蓝色条表示这个文件处于停止或暂停下载状态.你双击展开当前下载的文件,你可以看到它的源的下载进程条. (你可以在选项->常规中把这个操作改成单击. )这些进程条表示的意思稍微有点不同:(扁平风格)(圆滑风格)黑色表示这部分文件你已经下载了.蓝色这部分分你还没下载这部分这个源同样还没有下载到绿色这部分正在下载中黄色这部分正在请求下载中源的数目显示在进程条后面的四个如:xx / yy +aa (zz) 格式的数组表示当前这个文件的源的数目.它们的意义如下:• xx - 可用的源• yy - 源的总数• + aa - 正在请求另一个文件的源(高级选项打开)• zz - 正在传输的源已经得到的部分如果对方客户端软件支持,这个进程条会出现在上传列队中. 它显示当前文件对方客户的下载进度.黑色用户已经下载完成的部分还没找到的部分绿色正在上传的部分黄色正在请求的部分共享文件的有效性各个文件的有效性以一个条形显示. 条上色彩的意义和下载进度条是类似的.红色在所有已经找到的源中都没有这部分文件不同深度的蓝色显示这部分文件的分布情况eMule 下载的各类资源格式介绍eD2k 链接是一个特别的链接格式, 允许直接的加入一个下载到eMule. 这些链接允许eMule 直接的从web-管理员所提供他们的web 网页下载并且使它非常容易在这网络交换下载. 一个主要位置看起来像这样的链接eMule Content DB链接格式eMule 支持并且可以产生复杂的链接.•基本的eD2k 链接ed2k://|file||||/一个eD2k 链接包含必要的文件描述像是名称, 大小及哈希值形成基本的格式•eD2k 片段哈希值链接ed2k://|file||||p=|/在文件的完整的片段哈希值确保文件总是正确的并且帮助新的罕见的文件散布. •eD2k 来源链接ed2k://|file||||/|sources,|/加入一个或多个已知的eMule 来源在格式到这链接, 提供立即来源来下载. •eD2k 主机链接ed2k://|file||||/|sources,|/相同于来源链接但使用主机名称来替代IP. 特别是在变动IP 提供更灵活的. 一个主机名称必须设定在选项-> 扩展-> 自己的eD2K 链接主机名称•eD2k HTML 链接|||/">显示在web 网页名称容易的建立一个链接来显示在一个web 网页•eD2k HTTP 来源链接ed2k://|file||||s=/文件名称|/eMule 也能够直接的从web 来源下载. 一个对于web-管理员非常有用的且方便的格式. 见在下一段的Link Creator 了解更多信息.•eD2k 根哈希值链接ed2k://|file||||h=|/根哈希值链接允许由AICH 提供一个可靠的值来做进阶错误修正及检查的方式. 阅读这篇取得AICH 和根哈希值更进一步的信息.在eMule 建立链接在eMule 它非常容易的产生每个eD2k 链接除了HTTP 链接之外.在您的列表中选择任一个下载并按滑鼠右键:已共享文件主窗口提供已完成文件更多可能的选择:Link CreatorWeb 管理员释放流行软件常常面对拥挤的反应及在一个新的释放有非常大的流量问题. 提供web 下载来源并且eD2k 在相同链接能非常的有助于这个情形. 它提供使用者一个方便的方式来加入下载到eMule 的下载管理器, 散布文件在网络并且提供较大的下载速度透过HTTP 服务器.Link Creator是非常容易使用的工具能快速的产生这样的链接.只需输入文件来计算哈希值并且产生链接. 选择性的HTTP web 来源也许也能被加入. 使用移除按钮来移除一个已选择的HTTP 来源或是清除来移除全部.建议加入片段哈希值它可以改善下载的可靠性. 按下开始来产生链接.。
Emule Kad 网络分析
Emule Kad协议手册文档编写:kernel,huby版权所有: emuledev@一、概述 3二、协议参数分析 (3)2.1 BootStrap Req/Res (3)2.2 Hello Req/Res (4)2.3 Kad Req/Res (4)2.4 Kad Search/Publish Req/Res (6)2.5 Kad Firewalled Req/Res (6)2.6 Kad FindBuddy Req/Res (7)2.7 kad Callback Req (7)三、KAD Search Action (7)3.1、SendFindValue (8)3.2、StorePackt (8)3.2.1 GetInfo相关协议: (9)3.2.2 Publish 相关协议: (9)四、Emule Buddy机制分析 (9)4.1 网络协议包序列图: (10)五、Emule Kad 数据结构分析 (11)附录1( OPCode List): (12)附录2(Question List): (14)一、概述Kad使用UDP协议,通过eMule软件的UDP端口发送和接收数据这个宏定义了我能够接受的KAD最高版本#define KADEMLIA_VERSION 0x02在ed2k协议里面被使用CUpDownClient::SendHelloTypePacketKad版本:分为1.0和2.0区别:使用两套独立的opcode从2.0开始具有可扩展性,将版本信息写入协议,日后的扩展不再需要修改opcode0.47a默认使用的版本为Kad1.0,但是支持2.00.47c没有测试过KAD协议基本上是成对的一个REQ(Request)就有一个对应的RES(Respone)所有具有KAD头的包,(有些可能是压缩的),最终被送到Kademlia::Process中处理Process处理各种不同的opcode并将这些数据送到对应的处理函数,在REQ消息的处理函数中,解析发送过来的数据,并且构造RES数据包并发送出去二、协议参数分析2.1 BootStrap Req/Res0x00 KADEMLIA_BOOTSTRAP_REQ发送请求,这个时候急需扩大自己的KAD网络总共发送25B, 参照CKademliaUDPListener::SendMyDetails16B The sender Kad ID4B The sender IP2B The sender UDP Port2B The sender TCP Port1B 00x08 KADEMLIA_BOOTSTRAP_RESPacket Param: 返回20个Peer信息+自己的信息KADEMLIA2_BOOTSTRAP_REQKADEMLIA2_BOOTSTRAP_RES2.2 Hello Req/Res0x10 KADEMLIA_HELLO_REQ总共发送2B+25B, 参照CKademliaUDPListener::SendMyDetails1B OP_KADEMLIAHEADER1B byOpcode16B The sender Kad ID4B The sender IP2B The sender UDP Port2B The sender TCP Port1B 00x18 KADEMLIA_HELLO_RES回应KADEMLIA_HELLO_REQ,协议包格式和KADEMLIA_HELLO_REQ一样KADEMLIA2_HELLO_REQ参照CKademliaUDPListener::SendMyDetails1B OP_KADEMLIAHEADER1B byOpcode16B The Sender KadId2B The sender UDP Port1B KADEMLIA_VERSION1B Tag Count(2)1B+32B TAG_USER_COUNT(uint32)1B+32B TAG_FILE_COUNT(uint32)KADEMLIA2_HELLO_RES回应KADEMLIA2_HELLO_REQ,协议包格式和KADEMLIA2_HELLO_REQ一样我们可以看到,在2.0版本中,KadHello交换数据包括了自己Kad中已知的用户数和文件数, 但接收方都没有处理其中的Tag信息2.3 Kad Req/Res0x20 KADEMLIA_REQ向一个Contact发送KAD Search 请求,希望得到更接近一个Hash 值的Contact 信息Search类型包括:KADEMLIA_FIND_V ALUEKADEMLIA_STOREKADEMLIA_FIND_NODE参考CSearch::SendFindValue(CContact* pContact)1B OP_KADEMLIAHEADER1B byOpcode1B Search Tye16B Target Hash16B 当前Contacting 的Contact ID0x28 KADEMLIA_RES返回更接近一个hash value的Contact信息,这样我们可以获得更加逼近hash的Contact 信息,也就是说我们更加有可能找到含有这个hash信息的Contact 〔回应方不管具体的Search类型,只是把有更接近Target的Contact 发送给请求方〕参考CKademliaUDPListener::Process_KADEMLIA_REQ和CKademliaUDPListener::Process_KADEMLIA_RES1B OP_KADEMLIAHEADER1B byOpcode16B Target UINT1281B 更接近Target的Contact Count// Max count is 32. size 817.. // 16B + 1B + 25B(32)n*25B 16B Contact ID4B IP2B UDP Port2B TCP Port1B Type (发送这个信息时有填写ContactType值,但Response中处理的时候好像没处理)Kad2.00x21 KADEMLIA2_REQ参考CSearch::SendFindValue(CContact* pContact)1B OP_KADEMLIAHEADER1B byOpcode1B Search Tye16B Target Hash16B 当前Contacting 的Contact ID0x29 KADEMLIA2_RES2.4 Kad Search/Publish Req/Res在kad 网络内获取需要的索引信息或发布信息GetInfo 相关协议:KADEMLIA_SEARCH_REQ //UnUsed(老的协议)KADEMLIA_SEARCH_NOTES_REQ KADEMLIA2_SEARCH_KEY_REQ KADEMLIA2_SEARCH_SOURCE_REQ KADEMLIA2_SEARCH_NOTES_REQKADEMLIA_SEARCH_RES KADEMLIA_SEARCH_NOTES_RES KADEMLIA2_SEARCH_RESPublish 相关协议:KADEMLIA_PUBLISH_REQ //UnUsed(老的协议)KADEMLIA_PUBLISH_NOTES_REQ KADEMLIA2_PUBLISH_KEY_REQ KADEMLIA2_PUBLISH_SOURCE_REQ KADEMLIA2_PUBLISH_NOTES_REQKADEMLIA_PUBLISH_RES KADEMLIA_PUBLISH_NOTES_RES KADEMLIA2_PUBLISH_RES2.5 Kad Firewalled Req/Res请求别的Peer 检测自己是否FireWalled参考 CKademliaUDPListener::Process_KADEMLIA2_REQ 和 CKademliaUDPListener::Process_KADEMLIA2_RES 1B OP_KADEMLIAHEADER 1B byOpcode 16B Target UINT1281B 更接近Target 的Contact Count// Max count is 32. size 817.. // 16B + 1B + 25B(32) n*25B16B Contact ID 4B IP 2B UDP Port 2BTCP Port0x50 KADEMLIA_FIREWALLED_REQ0x58 KADEMLIA_FIREWALLED_RES2.6 Kad FindBuddy Req/ResEmule 中的LowId 需要积极主动找HighId作自己的Buddy,以便于和其它Peer通信Exam: LowId(A) 主动FindBuddy HighId(B)0x51 KADEMLIA_FINDBUDDY_REQ//packet param: <128bit Target(Low.A KadId~)><Low.A ClientHash><Low.A Port>0x5a KADEMLIA_FINDBUDDY_RES//packet param: <Low.A KadId~><High.B ClientHash><High.B Port>//B在接收到了FINDBUDDY_REQ之后,立即回答自己的TCP PortBuddy 之间互相保持通信联系:OP_BUDDYPING Param<NULL>OP_BUDDYPONG Param<NULL>20Minute间隔交互PINGPONG一次,并且HighId一方有防止LowId 频繁发送PING(LowId 至少必须间隔10Min发送一次)2.7 kad Callback Req0x52 KADEMLIA_CALLBACK_REQOP_CALLBACK三、KAD Search ActionKAD 网络中的Search 主要分为以下三组Action操作:#define KADEMLIA_FIND_V ALUE 0x02#define KADEMLIA_STORE 0x04#define KADEMLIA_FIND_NODE 0x0BActionType SearchType 说明KADEMLIA_FIND_V ALUE FILEKEYWORDNOTESFINDSOURCEKADEMLIA_STORE STOREFILESTOREKEYWORDSTORENOTES:FINDBUDDYKADEMLIA_FIND_NODE NODE:NODECOMPLETE:Kad的操作又分为两个阶段(Ⅰ)先尽量找到与Target最近的的Contact〔SendFindValue〕(Ⅱ)直到找不到更近的Contact后,就在当前最近的Contact开始做具体的StorePacket Value操作(Publish or GetInfo)[Emule目前代码实现是:一个Contact如果3s之内没有返回更接近Target的Contact,则可以对该Contact进行Value操作了]3.1、SendFindValue查找与Target 更接近的的Contact:# Trace: Kad SendFindValue(CContact* pContact) CallStackCSearch::Go( )|->CSearch::SendFindValue( ... )CSearch::JumpStart( )|->CSearch::SendFindValueCSearch::ProcessResponse|->CSearch::SendFindValue //从Res结果中筛选出最好,继续SendFindValue相关协议:KADEMLIA_REQKADEMLIA2_REQKADEMLIA_RESKADEMLIA2_RES3.2、StorePackt对Contact 发包,完成不同Action的Value操作(主要是Publish和GetInfo)#Trace: Csearch::StorePacktCKademlia::Process( )|->CSearchManager::JumpStart( )|->CSearch::JumpStart( )|->CSearch::StorePacket( )3.2.1 GetInfo相关协议:KADEMLIA_SEARCH_REQ //UnUsed(老的协议)KADEMLIA_SEARCH_NOTES_REQKADEMLIA2_SEARCH_KEY_REQKADEMLIA2_SEARCH_SOURCE_REQKADEMLIA2_SEARCH_NOTES_REQKADEMLIA_SEARCH_RESKADEMLIA_SEARCH_NOTES_RESKADEMLIA2_SEARCH_RES3.2.2 Publish 相关协议:KADEMLIA_PUBLISH_REQ //UnUsed(老的协议)KADEMLIA_PUBLISH_NOTES_REQKADEMLIA2_PUBLISH_KEY_REQKADEMLIA2_PUBLISH_SOURCE_REQKADEMLIA2_PUBLISH_NOTES_REQKADEMLIA_PUBLISH_RESKADEMLIA_PUBLISH_NOTES_RESKADEMLIA2_PUBLISH_RES四、Emule Buddy机制分析Emule 中的Buddy 机制是为了增进Emule中HihgId-LowId/LowId-LowId的通信,使得一个公网的Peer可以和处于NAT内的Peer之间相互通信,同时加上适当的策略,也可以让两个处于NAT内的Peer之间相互通信。
eMue片选择算法
eMue片选择算法由于从事eMule协议的相关开发已经有一段时间了,最近经常收到一些网友的邮件,探讨p2p网络中片选择的一些问题。
比如,在p2p假如一个文件被分为很多块,当有很多个client请求时,谁向谁请求哪些文件块,因为client和文件的提供者都是不断变化的啊。
不知道emule是怎样处理这个问题的。
就某一个时刻而言,client和文件的提供者是固定的,以什么样的规则请求文件块呢?对一个下载者来说,在选择下一个被下载的片断时,通常选择的是它的peers们所拥有的最少的那个片断,也就是所谓的"最少优先"。
确保了每个下载者都拥有它的peers们最希望得到的那些片断,从而一旦有需要,上载就可以开始。
这也确保了那些越普通的片断越放在最后下载,从而减少了这样一种可能性,即某个peer当前正提供上载,而随后却没有任何的被别人感兴趣的片断了。
也就说,每个peer都优先选择整个系统中最少的那些片断去下载,而那些在系统中相对较多的片断,放在后面下载,这样,整个系统就趋向于一种更优的状态。
如果不用这种算法,大家都去下载最多的那些片断,那么这些片断就会在系统中分布的越来越多,而那些在系统中相对较少的片断仍然很少,最后,某些peer 就不再拥有其它peer 感兴趣的片断了,那么系统的参与者越来越少,整个系统的性能就下降。
通常在下载的过程分为几个阶段,第一片选择,最后阶段模式,片选择要遵循的一个基本规则:一旦请求了某个片断的子片断,那么该片断剩下的子片断优先被请求。
这样,可以尽可能快的获得一个完整的片断。
每个文件被分成的块,每部分分成180KB的片。
块下载的顺序是由发送请求文件块消息(节)的下载客户端决定。
下载客户端可以在任何给定时刻从各个源中下载一个单独的文件块,所有从相同源中请求的片都在同一个块中。
下面的原理(以这个顺序)应用于下载块等级:1.(可获得的)大片的频率,尽可能快的下载非常稀少的大片来形成一个新的源。
emule客户端与客户端通信协议详解
客户端-客户端1初始化握手握手会话是对称的,客户端-客户端连接的两者都向对方发送相同的信息.两个客户端交换诸如识别,版本号和性能等信息.在这个过程中,有两种报文参与.其一,是Hello报文,它是eDonkey协议的一部分并与eDonkey客户端兼容;另一个报文是eMule信息报文,它属于eMule扩展协议.下图描述了两个eMule客户端之间的握手会话过程.在扩展信息中,包括有UDP报文交换,安全认证和源交换.客户端初始化握手2用户身份认证用户身份认证是eMule协议的一个扩展内容,只要客户端支持这种用户身份认证,它会在初始化握手之后立即完成.整个验证过程按如下步骤进行:1.在初始化握手过程中,客户端B表示它支持用户身份验证并期望使用此功能.2.客户端A对B的报文进行回应,它发送身份验证报文,并表明是否需要B的公钥.这个报文还包含了一个等待B回应的4字节挑战.3.如果A需要B的公钥,B将这个公钥发送给A.4.客户端B根据A发送的挑战和一个附加双字生成签名,并按照签名报文发送给A.此处的附加双字是根据B或A的IP产生的,当B是LowID时,这个双字为A的IP地址,当B为HighID时,这个双字为B的ID值.下图描述了身份验证过程.身份验证过程3文件请求客户端发送一些请求报文,请求下载它期望获得的文件.一个典型的成功的文件请求过程如图所示.文件请求过程3.1基本报文交换基本报文交换由四组报文组成,客户端A首先发送一个文件请求报文,紧接着发送一个请求文件ID报文.随后,客户端B发送文件请求应答和文件状态报文.eMule扩展协议在这个过程中还加入了一对源请求和源请求应答报文.这对扩展的报文交换可以将客户端B的源信息传给A.为了加强客户端的协作功能,客户端B可以在尚未完成下载的时候就将它已经完成的文件部分传给客户端A,即便客户端B仅仅下载了这个文件的一小部分.3.2未找到文件报文交换过程当客户端A向客户端B请求一个文件时,若B的共享文件列表中并没有这个文件,B将不发送文件请求应答报文,而是在客户端A发送文件ID请求后,立即发送一个未找到文件报文.详见下图.文件请求失败-未找到文件3.3加入上传队列当A和B完成文件请求的握手对话后,B客户端也有A客户端所需要的文件,然而此时B的上传队列并非为空(有其他客户端正在下载B的文件).在这种情况下,B会先将A添加在它的上传列队中,并发送给A一个队列排名报文,这个报文包含了A在队列中的位置以及B的上传队列的相关信息.详见下图.文件请求等待队列3.4达到队列顶端报文交换过程当客户端A到达客户端B的上传队列顶端,B将向A发出连接,进行初始化握手会话.接着,B向A发送一个接受上传请求报文.此时,若A选择继续并下载文件,它会向B发送一个请求文件部分报文;若A已经获得了这部分文件,则它会向B 发送一个取消传输报文.下图详细描述了这两种报文传递过程.达到队列顶端报文交换过程4.数据传输文件传输报文交换在文件请求应答后立即开始,此时待下载客户端A发送一个启动上传请求,目标客户端会回复一个接受上传请求报文.紧接着,客户端A开始请求文件部分,随后客户端B向其发送被请求的文件部分.此处的文件部分请求可以请求最多3个文件部分,所以,这样的情况下,一个文件部分请求报文最多会导致3个文件部分的传输过程.当上传下载客户端都支持eMule扩展协议时,文件部分可以压缩传输,同时,扩展协议还支持文件信息报文,这个报文会在接受上传请求前发送.文件传输报文交换过程详见下图.文件传输报文交换过程客户端-客户端UDP 通信eMule 客户端周期性的使用UDP 发送报文.UDP 报文仅用来查询客户端在其他上传客户端的队列中的位置.这是一个简单的查询-应答机制,首先由客户端发送一个询问文件报文.如下图所示,一共有三种不同的应答:1. 队列等级–客户端在上传队列重的等级.2. 队列已满–上传客户端的队列已满.3. 未找到文件–上传客户端并没有这个文件.这个询问报文约每20 分钟向每一个将其加入上传队列的客户端发送一次.附录:信用体制本段简述客户端的信用机制,如前所述,这种信用机制的主要目的在于鼓励上传.当一个上传客户端向一个下载客户端上传文件时,这个下载客户端会根据所收到的数据量增加对上传客户端的信用评价.此处的上传客户端信用并不是全局范围之内的,它的信用的增加只体现在当它下载此时这个下载客户端的某些文件时.也就是说,一个客户端的信用分别建立再各个它曾经上传过的客户端上.信用等级的计算如下:1.(总上传量*2)/总下载量.这个计算式的最大值取10,当总下载量为0时,此值默认为10.2.Sqrt(总上传量+2).当总上传量小于1Mb时,这个表达式最小值取1.总下载/上传量都以Mb为单位进行计算,按上边的公式,一个客户端的信用等级为一个取值范围为1到10的数.上传队列管理客户端为每个上传文件维护一个上传优先级队列,在这个上传队列中,待下载客户端的优先级是根据它在这个队列中的时间以及一个优先级参数共同计算的.在队列的顶端是优先级得分最高的客户端.具体的优先级计算公式为:优先级=(等级*在队列中时间)/100.此处的等级值有如下几个情况,若对方客户端为好友,则此值为无穷大,即表明好友的优先级为无穷大,直接到达队列顶端开始下载.若客户端为普通待下载客户端,等级的初始值为100.若对方为被禁止的客户端,则此值为0,使其永远无法到达队列顶端,拒绝其下载要求.对于普通用户而言,这个等级值随后根据客户端信用和下载文件本身的优先级变化,下载文件优先级取值范围为0.2-1.8,上传用户可以对此进行调整.当一个待下载客户端比队列里的其他客户端具有更高的优先级时,它便开始下载.它将保持下载直到发生以下情况:1.上传客户端退出.2.下载客户端下载完毕.3.待下载队列中有其他客户端优先级超过了正在下载的客户端优先级.为了可以让正在下载客户端完成至少一定量的下载,eMule上传客户端会在下载开始前十五分钟将下载的等级调到200以防止频繁的下载竞争.下载选择eMule客户端会按照一定规则选择下载文件各部分的顺序,通过这样的机制,试图达到整个网络共享的优化.如前所述,共享的文件都按照9.28Mb为单位分割为文件部分,每个部分又被细分为180Kb的文件块.文件部分的下载顺序由下载客户端所决定,它在下载时发送文件部分下载请求报文.下载客户端可以在任意已知的源处下载任意未获得的文件部分,一个部分内的各个文件块则从同一个源处获得.文件部分的下载顺序依照如下原则进行选择:1.按可获得文件块选择:极稀缺文件块应以最快速度下载,从而未其他客户端做源.2.用于预览和检查的文件块先下载.3.按请求要求:从不同源出按请求顺序下载.4.按完成速度:即将完成的文件块优先下载.在衡量文件部分下载顺序时,引入频率参数.它可被划分为极稀缺,稀缺和普通.在这三种情况下,计算文件部分等级时,频率分别有不同的影响加权.文件部分的下载等级值越低则越先被下载.这个值的计算方法如下:•0-9999–被请求或未被请求的极稀缺文件部分.•10000-19999–未被请求的稀缺文件部分和预览文件部分.•20000-29999–未被请求的即将完成文件.•30000-39999–被请求的稀缺文件部分和预览文件部分.•40000-49999–被请求的普通文件部分.这个算法总是选择最稀缺的文件部分进行优先下载,即将下载完成的文件部分也会被优先选择.对于普通文件部分而言,会在许多不同的源处下载.数据包eMule网络活动主要在于发送和接受文件部分.一个文件部分的大小由5000到15000字节.为了防止产生文件碎片,一个文件部分报文被分开在一个TCP数据包的许多片断内.以eMule0.30e客户端为例,其最大片断大小为1300字节.这又就是说,尽管控制类的报文都在一个TCP数据包中完全包含,而有的时候数据报文是被分在几个TCP包中的.其中,第一个包中包含了传送部分的报文头,其后的包中就只包含数据.如果当文件被1300字节整除而有余数时,不足一个包的数据将和报文头一起放在第一个包中.。
eMule电驴eDonkey源代码精辟分析
eMule电驴eDonkey源代码精辟分析最近给一家公司写一个类似电驴的P2P客户端.写的相当的累,但是收获也很大,对电驴的代码进行了深入的分析,现在把所得贡献给大家,网上有很多对电驴协议的分析,其实有些地方是误导大家了,中国的程序员还是很小家子气,就是怕别人超过自己.进入正题,电驴的协议和各种常量参数定义在opcodes.h中,#define OP_EDONKEYHEADER 0xE3#define OP_KADEMLIAHEADER 0xE4这是他的协议码,他大部分的通信包第一个字节都是OP_EDONKEYHEADER 0xE3,这是他的客户端之间的协议#define OP_HELLO 0x01 // 0x10<HASH 16><ID 4><PORT 2><1 Tag_set>#define OP_SENDINGPART 0x46 // <HASH 16><von 4><bis 4><Daten len:(von-bis)>#define OP_REQUESTPARTS 0x47 // <HASH 16><von[3] 4*3><bis[3] 4*3>#define OP_FILEREQANSNOFIL 0x48 // <HASH 16>#define OP_END_OF_DOWNLOAD 0x49 // <HASH 16>#define OP_ASKSHAREDFILES 0x4A // (null)#define OP_ASKSHAREDFILESANSWER 0x4B // <count 4>(<HASH 16><ID 4><PORT 2><1 Tag_set>)[count]#define OP_HELLOANSWER 0x4C // <HASH 16><ID 4><PORT 2><1 Tag_set><SERVER_IP 4><SERVER_PORT 2>#define OP_CHANGE_CLIENT_ID 0x4D // <ID_old 4><ID_new 4>#define OP_MESSAGE 0x4E // <len 2><Message len>#define OP_SETREQFILEID 0x4F // <HASH 16>#define OP_FILESTA TUS 0x50 // <HASH 16><count 2><status(bit array) len:((count+7)/8)> #define OP_HASHSETREQUEST 0x51 // <HASH 16>#define OP_HASHSETANSWER 0x52 // <count 2><HASH[count] 16*count>#define OP_STARTUPLOADREQ 0x54 // <HASH 16>#define OP_ACCEPTUPLOADREQ 0x55 // (null)#define OP_CANCELTRANSFER 0x56 // (null)#define OP_OUTOFPARTREQS 0x57 // (null)#define OP_REQUESTFILENAME 0x58 // <HASH 16> (more correctly file_name_request)#define OP_REQFILENAMEANSWER 0x59 // <HASH 16><len 4><NAME len>#define OP_CHANGE_SLOT 0x5B // <HASH 16>#define OP_QUEUERANK 0x5C // <wert 4> (slot index of the request)#define OP_ASKSHAREDDIRS 0x5D // (null)#define OP_ASKSHAREDFILESDIR 0x5E // <len 2><Directory len>#define OP_ASKSHAREDDIRSANS 0x5F // <count 4>(<len 2><Directory len>)[count]#define OP_ASKSHAREDFILESDIRANS 0x60 // <len 2><Directory len><count 4>(<HASH 16><ID 4><PORT 2><1 Tag_set>)[count]#define OP_ASKSHAREDDENIEDANS 0x61 // (null)这是他的客户端到服务器的通信协议// client <-> server#define OP_LOGINREQUEST 0x01 //<HASH 16><ID 4><PORT 2><1 Tag_set>#define OP_REJECT 0x05 //(null)#define OP_GETSERVERLIST 0x14 //(null)client->server#define OP_OFFERFILES 0x15 // <count 4>(<HASH 16><ID 4><PORT 2><1 Tag_set>)[count]#define OP_SEARCHREQUEST 0x16 // <Query_Tree>#define OP_DISCONNECT 0x18 // (not verified)#define OP_GETSOURCES 0x19 // <HASH 16>#define OP_SEARCH_USER 0x1A // <Query_Tree>#define OP_CALLBACKREQUEST 0x1C // <ID 4>#define OP_QUERY_CHA TS 0x1D // (deprecated not supported by server any longer)#define OP_CHA T_MESSAGE 0x1E // (deprecated not supported by server any longer)#define OP_JOIN_ROOM 0x1F // (deprecated not supported by server any longer)#define OP_QUERY_MORE_RESULT 0x21 // (null)#define OP_SERVERLIST 0x32 // <count 1>(<IP 4><PORT 2>)[count] server->client#define OP_SEARCHRESULT 0x33 // <count 4>(<HASH 16><ID 4><PORT 2><1 Tag_set>)[count]#define OP_SERVERSTA TUS 0x34 // <USER 4><FILES 4>#define OP_CALLBACKREQUESTED 0x35 // <IP 4><PORT 2>#define OP_CALLBACK_FAIL 0x36 // (null notverified)#define OP_SERVERMESSAGE 0x38 // <len 2><Message len>#define OP_CHA T_ROOM_REQUEST 0x39 // (deprecated not supported by server any longer)#define OP_CHA T_BROADCAST 0x3A// (deprecated not supported by server any longer)#define OP_CHA T_USER_JOIN 0x3B // (deprecated not supported by server any longer)#define OP_CHA T_USER_LEA VE 0x3C // (deprecated not supported by server any longer)#define OP_CHA T_USER 0x3D // (deprecated not supported by server any longer)#define OP_IDCHANGE 0x40 // <NEW_ID 4><server_flags 4><primary_tcp_port 4 (unused)><client_IP_address 4>#define OP_SERVERIDENT 0x41 // <HASH 16><IP 4><PORT 2>{1 TAG_SET}#define OP_FOUNDSOURCES 0x42 // <HASH 16><count 1>(<ID 4><PORT 2>)[count]#define OP_USERS_LIST 0x43 // <count 4>(<HASH 16><ID 4><PORT 2><1 Tag_set>)[count]#define OP_GETSOURCES_OBFU 0x23#define OP_FOUNDSOURCES_OBFU 0x44电驴的Socket网络通信部分写的超级搞笑,听我慢慢道来首先EMSocket.h这个类是他的业务通信类可以清楚的看到他的协议头部分是个#define PACKET_HEADER_SIZE 6字节看他的接收是一个静态缓冲区static char GlobalReadBuffer[10*1024*1024];10M大小在接收时候大于8K的使用10M设置,小于8k的使用8Kuint32 recvbufferlimit = 2*ret;if (recvbufferlimit > (10*1024*1024)) {recvbufferlimit = (10*1024*1024);} else if (recvbufferlimit < 8192) {recvbufferlimit = 8192;}if (recvbufferlimit > m_uCurrentRecvBufferSize) {SetSockOpt(SO_RCVBUF, &recvbufferlimit, sizeof(recvbufferlimit), SOL_SOCKET);}int ilen = sizeof(int);GetSockOpt(SO_RCVBUF, &recvbufferlimit, &ilen, SOL_SOCKET);发送的时候Send(1300, 0, true);以1300MTU发送.然后在谈一下他的爷爷,他的爸爸CEncryptedStreamSocket先略去不讲class CEncryptedStreamSocket : public CAsyncSocketEx讲CAsyncSocketEx这个可是电驴最核心的通信类,他直接继承于MFC的祖宗CObject大家注意我这里会讲到电驴SOCKET的命脉所在,这是在整个互联网上还没有人讲的,我最先发布电驴的网络控制是在每一个CAsyncSocketEx中包含了一个窗口句柄,利用这个窗口来派发所有的socket通信控制这是他的SOCKETstruct t_AsyncSocketExData{SOCKET hSocket; //Socket handleint nSocketIndex; //Index of socket, required by CAsyncSocketExHelperWindow} m_SocketData;这是他的那个消息窗口struct t_AsyncSocketExThreadData{CAsyncSocketExHelperWindow *m_pHelperWindow;int nInstanceCount;DWORD nThreadId;} *m_pLocalAsyncSocketExThreadData;这是包含所有窗口句柄的链表//List of the data structures for all threadsstatic struct t_AsyncSocketExThreadDataList{t_AsyncSocketExThreadDataList *pNext;t_AsyncSocketExThreadData *pThreadData;} *m_spAsyncSocketExThreadDataList;然后大家去AsyncSocketEx.cpp中看class CAsyncSocketExHelperWindow的类实现吧,他的所有的SOCKET行为都在这里了.当然这只是通信的开始,后续代码分析我会在今后的博客中为大家见讲解。
电驴下载地址小解析
我们以这个地址为例
ed2k://|file|Mission.Impossible.Ghost.Protocol.2011.碟中谍4:幽灵协议.双语字幕.HR-HDTV.AC3.1024X576.x264-人人影视制作.mkv|2379113665|72ad435492ca4d2eee48b51ebb2ddf09|h=euzhiemf4isn5czwg3mjxdxkachu5hvg|/
电驴下载属于一种P2P下载方式,它的下载地址能被所有主流下载软件所使用,而对于我们学校而言,使用电驴下载地址进行文件的下载再好不过了。我个人比较喜欢在“人人影视”网上下载电影和美剧。但有时候我们会遇到电驴地址出错的时候,将地址黏贴到下载软件中进行下载时,往往有得会提示“ed2k或hash出错”(反正就这个意思),不知道大家是怎么解决这个问题的,可能你会放弃或者是在寻找别的类型的下载地址进行下载。闲着无聊我简单的研究了一下电驴的下载地址(原因是我昨天下载时遇到此问题了,我不甘心就这样放弃 ),或许能对各位有所帮助
如何让电驴跑的快
如何让电驴跑的快- eMule加速分类:酷软推荐现在很多人都开始使用电驴了~但是很多朋友也发现,自己的驴子跑的好慢啊~并不像其他朋友说的那么惬意啊~下面提供了一些小小的方法~对我们的驴子加强马力~效果还是不错的哦公网用户告别LowID(这个也最简单)公网用户得到LowID大都是因为开了防火墙的关系,关闭防火墙或在防火墙里为eMule设置相应的端口即可。
从0.43a版起,eMule 默认启动时自动将WindowsXP的防火墙中打开自己连接设置里的TCP/UDP端口。
如下图所示,以确保您的设置正确:而且可以在eMule里手动打开WindowsXP的防火墙。
进入eMule的连接设置,如下图:可以看到eMule的端口,默认是4662,建议可以更换其他的,因为有些ISP封锁了4662端口(主要是国外的,因为那里eMule下载太厉害了,哈哈),如果你还是使用4662端口的话,将无法连接那些ISP下的eMule(端口随便找个大一点的自己看得爽的数字填好了~一般不会冲突。
然后点击“打开WinXP防火墙中的这些端口”,这样eMule就自动在WindowsXP中为您打开了所选择的端口。
如果您的eMule没有成功打开TCP端口,可以按照以下步骤手动为防火墙开启这些端口。
打开“本地连接”的属性点击“属性”在“高级”选项卡中点击“设置”在“例外”选项卡中点击“添加端口”按钮名称填写“eMule”,端口号填你eMule选项->连接->客户端口->TCP端口的数字,点击确定。
如果还装有第三方防火墙,比如诺顿网络特警、金山网镖等,还需要手动打开这些防火墙的相应的TCP端口。
这里就不一一介绍了。
全部设置好就OK了,重新连接即可享受HighID啦~~~局域网用户告别LowID一般通过局域网上网的有三种情况:1.企业内部网、城域网、小区网,就是指大规模的的局域网结构,比如校园网、某些地区的FTTB、长城宽带等。
这类用户除非认识网管,否则还是无法解决LowID的问题。
数字媒体艺术概论参考笔记
第一章数字媒体艺术设计概论5突出表现:“数字绘画艺术”或“电脑美术”。
应用表现形式:借助数字技术或数字媒体来创作的其他视觉艺术或设计作品。
6本质和内涵:是基于数字媒体的一门艺术,是视觉艺术、设计学、计算机图形图像学和媒体技术相互交叉的学科。
核心:艺术设计和计算机科学与技术的交叉表现形式:电子媒体或数字媒体表达内容:多是数字媒体形式的美术作品或设计作品媒体传播形式:借助于新媒体形式或数字载体研究重点:如何应用数字艺术创作工具(即图形图像软件),根据人的需求和艺术设计规律来创作和表现具有视觉美感的艺术作品或服务业产品,并基于数字媒体时空来延伸和发展人类的艺术创造力和想象力。
7.计算机图形学、视觉艺术和数字媒体技术三者的结合部分划为数字媒体艺术设计8.数字媒体艺术的科技依赖性(分形,描述生物有机体的特征或模拟自然界的山川河流、创作者和观赏者对硬件的依赖)人惊奇的异常神秘,迷一般的形象为特征——幻觉效应。
对这个复杂世界、社会以及自我心灵的全方位的解构,而且充满那可爱的“游戏”的感觉。
2.技巧难度即他称之为“炼金术”般神秘的暗房技术8.“人文画”特点是写意,散点透视法和线描塑造形象,作画时保留最能表现物我精神气质的形象特征。
“集锦派”摄影艺术大师朗静山摄影是形象逼真、传递迅速的一种艺术手段《红树青山》极像一幅国画立轴,远山近树都十分清晰,层次丰富而不失纵深感,融合画理、意境深远的集锦照片,由此奠定“集锦派”摄影理论基础。
9.数字媒体艺术美学思想起源达达主义的“异类合成”美学(多种异质美学的杂交,为其表征、形式、构成、分解、起源、过程、或结果)10.数字媒体艺术表现多样性①时空反转埃舍尔的时空幻觉艺术达利的多重合理空间组合的不合理性②意识和潜意识更重视潜意识的范畴,是一种超理性、超意识的艺术③气氛铺陈彩度明度制造特殊的气氛效果或怪异的空间环境④拼贴重组对达达主义的继承和扬弃,遵循非理性拼贴与矛盾并置的结构原则⑤制造矛盾和荒诞利用物体的比例、质感产生矛盾感⑥幻觉与真实视觉上产生真实的物体造型,实际是科技产生的幻觉影像(≈尤斯曼后期制作)⑦抽象的意象将有机和无机物重新组合形成超现实抽象意境11.互动性让不同的媒体形态相互联结,以其特性以求对观者有所吸引,给于自主权的控制,以观者为优先的控制模式,建立彼此的互动性。
Emule分析
文件基础设施类Preferences.h基础信息配置类Statistics.h信息统计类Emule 文中件基础设施类:kademlia\io下面完成各种格式的配置文件的读写:两个基类文件SafeFile.h实现的CFileDataIO类和DataIO.h文件中实现的CDataIO字符串转化的基础设施StringConversion.cpp中实现CKnownFileList类管理自己共享的文件信息网络基础设施类CAsyncSocketEx类以替代MFC中的CAsyncSocket类,它提供了所有CAsyncSocket方法,并提供了一些增强方法,效率上都有所提高,主要是在消息的分发机制上。
支持通过实现CAsyncSocketExLayer类的方式,将一个Socket灵活地分成若干层。
两个实现限速功能类:ThrottledControlSocket类和ThrottledFileSocket类,只要继承这两个类,就能实现限速功能。
CEncryptedDatagramSocket类,提供对UDP包进行加解密的功能。
CEMSocket类,提供对TCP流进行加解密、指定代理、加密数据等。
UploadBandwidthThrottler类:全局上传限速类,继承了CWinThread类。
通信协议eMule协议是由 Packet类实现的。
Opcodes.h:定义了eMule协议中的各字段。
Packets.h中宣言了协议的构造和解析CServerSocket类负责处理客户端与服务器之间TCP连接发送的数据包。
CClientReqSocket类负责处理客户端之间TCP连接发送的数据包。
任务处理机制分块机制:CKnowFile类中的CreateFromFile函数实现,文件分块机制。
将一个大文件组织成一棵树。
CAICHHash类,负责存储文件块的散列值,提供赋值,比较等运算符的重载操作。
CAICHHashAlgo类,是一个计算散列值的算法接口类。
eMule问题解决大全
eMule问题解决大全1、什么是ED?ED是edonkey的英文缩写,在P2P里是用户最多,协议比较好的共享软件。
在ED网络里,你可以共享文件上传给其他用户,其他用户也可以共享文件提供给你下载。
最初,只有eDonkey一种客户端,后来,在ED协议的基础上发展出许多客户端,例如:MLdonkey、BOT、xMule、cDonkey、shareaza、eD Hybird、eMule(MLdonkey、BOT被许多服务器禁止登录)。
其中最好的一种客户端是eMule,使用者也最多。
eMule由于是开放源码,因此eMule里拥有众多的MOD,比如LSD、plus等。
本论坛推荐使用的acat版也是eMule里的MOD之一。
2、什么是ED链接ED的下载可以通过ED软件的搜索功能实现,但当你希望共享你独有的东东时,就需要发布"ED链接",如下蓝色的就是一个ED链接,ED链接用"|"号分成几个部分ed2k://|file|Tom.and.Jerry.Vol1.DVDRip.XviD-WRD.avi|729083904|705B0FC AF6EF1D69A0C6DA994E4AB42D|/ed2k:// 这是ED链接的标志,就像网址用HTTP://是相同的道理file 这个不用说大家也知道, 文件啰Tom.and.Jerry.Vol1.DVDRip.XviD-WRD.avi 这个就是你要发布或下载的文件名729083904 文件的大小字节数705B0FCAF6EF1D69A0C6DA994E4AB42D 文件hash,它就是ED网络对于共享文件的唯一识别标记, 34的32次方,不用担心它会重复在emule=>选项=>常规=>点击"ED2K链接",使这个按钮变成灰色,当你获得一个ED链接时,将它复制到IE浏览器的地址栏,就会自动加入到已开启的eMule 下载任务中了3、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.1202003-12-8 17:51:32: 新的客户ID为3478929370红色的就是本人小小驴的UserHash,新来的驴友可能对EM的UserHash比较陌生,下面我们来了解一下。
什么是迅雷、电骡
电骡目录备注什么是eMule的MODeMule 起源eMule 表示什么?VeryCD 版eMule 特色ED2000版eMule 特色eMule 与其他P2P 软件相比的优点及特色认识电驴∙附录:P2P 定义∙GNU GPL∙电驴电骡到底叫什么才正确?[编辑本段]备注请同时参考词条“电驴”。
eMule在哪里?在这里:/什么是eMule?在2002年5月13日的黎明,一个叫Merkur的人对原始的eDonkey2000客户端感到不满,他坚信他能做的更好。
然后他就那么去做了。
他在自己的周围聚集了很多的开发人员,eMule工程也由此诞生。
他们的目标是将eDonkey的精华保留下来,增加新的功能,并使图形界面更加友好。
他们无法想象此时的决定会带来什么样的影响……今天,eMule是世界上最大最可靠的点对点文件共享客户端之一。
由于它奉行开发源代码的政策,众多的开发者得以对eMule工程有所贡献。
随着每一个版本的发布,eMule的开发者网络都变得更有效率。
eMule是什么意思?eMule(电骡)来自一种叫做“骡子”的动物,提醒你一下,就是那种有点像驴的家伙。
;)eMule多长时间更新一次?eMule并不是有规律的更新和升级的,一般是一周到三周一次,但是不总是这样。
:)一些eMule具有的功能:·客户端使用若干种网络来建立一个可靠的传输网络(ED2K,来源交换和Kad)·Kad正处于开放测试阶段,eMule 0.42以后的版本中都包含了Kad功能。
·eMule的队列和信用系统确保每个人通过上传文件、回馈给整个网络的方式来获得自己想要的文件。
·eMule是完全免费的,它也决不包含广告软件、间谍和流氓软件。
我们之所以创造eMule是为了快乐和知识,而不是为了金钱。
·每个下载的文件都会自动检查是否损坏,以确保文件的正确性。
·eMule的智能损坏控制系统有助于快速纠正在传输中损坏的部分。
电驴(emule/edonkey)教程
电驴(emule/edonkey)教程前言——文件搜索新时代的开创者:电驴回顾上网伊始,网民寻找网站都是沿着各网站提供链接,自主权、选择权相对受到限制。
但是当Yahoo、Lycos、Google、百度等建立了搜索引擎后,网友上网冲浪的方式有所改变,可以利用搜索引擎去查找获取自己需要的所有信息。
类似于网站、网页的搜索引擎,电驴是文件的搜索引擎。
可以说,电驴的推出开创了文件搜索新时代。
何为电驴?英文名称edonkey。
用户用电驴软件把各自的PC连接到电驴服务器上,而服务器的作用仅是收集连接到服务器的各电驴用户的共享文件信息(并不存放任何共享文件),并指导P2P下载方式。
P2P就是Point To Point,也可以理解为PC To PC或Peer To Peer,所以电驴用户既是client,同时也是server。
可以说,电驴把控制权真正交与用户手中,用户通过电驴可以共享硬盘上的文件、目录甚至整个硬盘。
那些费心收集存储在自己硬盘上的文件肯定是被认为最有价值的。
所有用户都共享了他们认为最有价值的文件,这将使互联网上信息的价值得到极大的提升。
看到这里,你是不是有一种第一次见到网络、搜索引擎时的激动呢?本傻瓜教程将本着循序渐进的原则,力图使大家快速掌握电驴技术。
学完第一课,就可以使用电驴了,学完前三课,就可以熟练使用电驴了,学完本教程,就完全可以算是名副其实的电驴高手了!!!你不必一次学完,可一课一课仔细领会,逐步提高骑驴技术。
本教程所使用的软件为emule V0.28a版本,简单易学,该版本解决了以前emule软件不能支持代理的问题。
========================================================================= ====第一课——文件下载第1步、下载软件(emule或edonkey)电驴软件很多,我用的是emule,也就是电骡。
该软件界面有简体中文及多种语言,为大多数电驴用户使用。
eMule资源发布全攻略
eMule资源发布初级攻略如果您觉得使用Http和Ftp方式下载的资源越来越少,而又畏惧BT资源的混乱无序,那么电骡子(eMule)也许是你唯一的选择了。
(图1 VeryCD首页上丰富的eMule资源)推荐电骡首先是电骡的宗旨很好:“我为人人,人人为我”。
相比于PUB,用句时髦的话,电骡应该是“绿色环保”,因为所有的电骡用户文件都是自己主动希望共享的,而不用去窃取其他用户的空间,因而也不会造成大量的网络垃圾。
其次使用电骡可以搜索到几乎你想搜索到的所有文件,我近来就将目标逐步转移到音乐、软件和英文电影方面了。
我也建议大家多使用电骡和Google,有了这两部海量百科全书,有什么问题不能自己解决呢?对比FTP和PUB,使用电骡更有利于培养良好的网络习惯。
你完全可以定期选好片子,然后安心去工作、学习、上网。
让骡儿自己去吃草,你全力去做其他更有价值的事情,何乐而不为呢?一、骡子(eMule)的故事2002年05月13日一个叫做 Merkur 的人,他不满意当时的eDonkey2000 客户端并且坚信他能做出更出色的 P2P 软件,于是便着手开发。
他凝聚了一批原本在其他领域有出色发挥的程序员在他的周围,eMule 工程就此诞生。
他的目标是将 eDonkey 的优点及精华保留下来,并加入新的功能以及使图形界面变得更好。
今天,eMule 已是世界上最大并且最可靠的点对点文档共享的客户端软件。
开放源代码的政策,使许多开发人员能够对这个工程有所贡献。
eMule 的优势:1、eMule是完全免费的,即使官方版 eMule 也完全沒有任何的广告软件。
2、每个下载的文件都会自动检查是否损坏以确保文件的正确性(FTP却不能保证精确复制),智慧损坏控制有助于快速修复损坏的部分。
3、自动优先权及来源管理系统允许您一次下载许多个资源而无须监视它们。
4、预览功能允许您在下载完成之前查看视频文件。
5、eMule 的 Web 服务特性和 Web 服务器允许您快速得从网络存取资料。
emule架构分析
eMule是一个典型的MFC程序,它的图形界面等,已经和MFC紧紧融合到了一起。
因此通常情况下它只能在windows平台下运行。
有一些其它的工程,如aMule等,把它进行了移植,因此跨平台的功能要强些。
其实还有另外一个叫做xMule的工程,不过现在已经人气快不行了。
在aMule 的主页上可以看到eMule移植到linux平台下的一些历史,最早是有个叫做lMule的工程,他使用wxwidgets来进行eMule的跨平台的移植,这个工程2003年就不再更新了,后来转变成为xMule工程,它一度是linux平台下eMule 的事实上的替代品。
但是他们的程序员之间由于理念不同,发生了内讧,导致aMule分裂出来,他们后来矛盾严重的时候曾经一度从理念问题上升到互相对对方进行人身攻击,并且曾经对对方的网站发动过DDos。
后来aMule和xMule 就是两个完全不同的工程,xMule现在只有HopeSeekr一个人在维护,基本上也没有什么更新了。
这一点不仅让人感慨。
今年寒假的时候我曾经和HopeSeekr进行过一些交流,感觉他非常自信,经常拿着aMule的一部分代码来给我看,说你看看他们的代码这么这么写,这简直就是一陀xx嘛,这种代码在某些情况下肯定会Crash掉嘛,相反,你看看我们xMule的代码,这里是这样这样,肯定就不会有这种问题了。
eMule从0.42版开始支持Kad技术,这是一个非常重要的里程碑。
Kad是一种DHT的协议,它可以使节点之间互相保留一些其它节点的联系信息,并且利用这样一个“关系网”寻找到整个网络中的任何一个节点以及上面的资源,整个过程不需要任何中心服务器。
因此向当年搞napster那样直接端掉中心服务器就搞跨napster网络一样来对付eMule的Kad网就毫无作用了。
0.42版是2004年2月27日放出的,比eDonkey2000的OverNet晚了将近一年,但是它的Kad网络的规模却在迅速扩大。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
eMule电驴eDonkey源代码精辟分析最近给一家公司写一个类似电驴的P2P客户端.写的相当的累,但是收获也很大,对电驴的代码进行了深入的分析,现在把所得贡献给大家,网上有很多对电驴协议的分析,其实有些地方是误导大家了,中国的程序员还是很小家子气,就是怕别人超过自己.进入正题,电驴的协议和各种常量参数定义在opcodes.h中,#define OP_EDONKEYHEADER 0xE3#define OP_KADEMLIAHEADER 0xE4这是他的协议码,他大部分的通信包第一个字节都是OP_EDONKEYHEADER 0xE3,这是他的客户端之间的协议#define OP_HELLO 0x01 // 0x10<HASH 16><ID 4><PORT 2><1 Tag_set>#define OP_SENDINGPART 0x46 // <HASH 16><von 4><bis 4><Daten len:(von-bis)>#define OP_REQUESTPARTS 0x47 // <HASH 16><von[3] 4*3><bis[3] 4*3>#define OP_FILEREQANSNOFIL 0x48 // <HASH 16>#define OP_END_OF_DOWNLOAD 0x49 // <HASH 16>#define OP_ASKSHAREDFILES 0x4A // (null)#define OP_ASKSHAREDFILESANSWER 0x4B // <count 4>(<HASH 16><ID 4><PORT 2><1 Tag_set>)[count]#define OP_HELLOANSWER 0x4C // <HASH 16><ID 4><PORT 2><1 Tag_set><SERVER_IP 4><SERVER_PORT 2>#define OP_CHANGE_CLIENT_ID 0x4D // <ID_old 4><ID_new 4>#define OP_MESSAGE 0x4E // <len 2><Message len>#define OP_SETREQFILEID 0x4F // <HASH 16>#define OP_FILESTA TUS 0x50 // <HASH 16><count 2><status(bit array) len:((count+7)/8)> #define OP_HASHSETREQUEST 0x51 // <HASH 16>#define OP_HASHSETANSWER 0x52 // <count 2><HASH[count] 16*count>#define OP_STARTUPLOADREQ 0x54 // <HASH 16>#define OP_ACCEPTUPLOADREQ 0x55 // (null)#define OP_CANCELTRANSFER 0x56 // (null)#define OP_OUTOFPARTREQS 0x57 // (null)#define OP_REQUESTFILENAME 0x58 // <HASH 16> (more correctly file_name_request)#define OP_REQFILENAMEANSWER 0x59 // <HASH 16><len 4><NAME len>#define OP_CHANGE_SLOT 0x5B // <HASH 16>#define OP_QUEUERANK 0x5C // <wert 4> (slot index of the request)#define OP_ASKSHAREDDIRS 0x5D // (null)#define OP_ASKSHAREDFILESDIR 0x5E // <len 2><Directory len>#define OP_ASKSHAREDDIRSANS 0x5F // <count 4>(<len 2><Directory len>)[count]#define OP_ASKSHAREDFILESDIRANS 0x60 // <len 2><Directory len><count 4>(<HASH 16><ID 4><PORT 2><1 Tag_set>)[count]#define OP_ASKSHAREDDENIEDANS 0x61 // (null)这是他的客户端到服务器的通信协议// client <-> server#define OP_LOGINREQUEST 0x01 //<HASH 16><ID 4><PORT 2><1 Tag_set>#define OP_REJECT 0x05 //(null)#define OP_GETSERVERLIST 0x14 //(null)client->server#define OP_OFFERFILES 0x15 // <count 4>(<HASH 16><ID 4><PORT 2><1 Tag_set>)[count]#define OP_SEARCHREQUEST 0x16 // <Query_Tree>#define OP_DISCONNECT 0x18 // (not verified)#define OP_GETSOURCES 0x19 // <HASH 16>#define OP_SEARCH_USER 0x1A // <Query_Tree>#define OP_CALLBACKREQUEST 0x1C // <ID 4>#define OP_QUERY_CHA TS 0x1D // (deprecated not supported by server any longer)#define OP_CHA T_MESSAGE 0x1E // (deprecated not supported by server any longer)#define OP_JOIN_ROOM 0x1F // (deprecated not supported by server any longer)#define OP_QUERY_MORE_RESULT 0x21 // (null)#define OP_SERVERLIST 0x32 // <count 1>(<IP 4><PORT 2>)[count] server->client#define OP_SEARCHRESULT 0x33 // <count 4>(<HASH 16><ID 4><PORT 2><1 Tag_set>)[count]#define OP_SERVERSTA TUS 0x34 // <USER 4><FILES 4>#define OP_CALLBACKREQUESTED 0x35 // <IP 4><PORT 2>#define OP_CALLBACK_FAIL 0x36 // (null notverified)#define OP_SERVERMESSAGE 0x38 // <len 2><Message len>#define OP_CHA T_ROOM_REQUEST 0x39 // (deprecated not supported by server any longer)#define OP_CHA T_BROADCAST 0x3A// (deprecated not supported by server any longer)#define OP_CHA T_USER_JOIN 0x3B // (deprecated not supported by server any longer)#define OP_CHA T_USER_LEA VE 0x3C // (deprecated not supported by server any longer)#define OP_CHA T_USER 0x3D // (deprecated not supported by server any longer)#define OP_IDCHANGE 0x40 // <NEW_ID 4><server_flags 4><primary_tcp_port 4 (unused)><client_IP_address 4>#define OP_SERVERIDENT 0x41 // <HASH 16><IP 4><PORT 2>{1 TAG_SET}#define OP_FOUNDSOURCES 0x42 // <HASH 16><count 1>(<ID 4><PORT 2>)[count]#define OP_USERS_LIST 0x43 // <count 4>(<HASH 16><ID 4><PORT 2><1 Tag_set>)[count]#define OP_GETSOURCES_OBFU 0x23#define OP_FOUNDSOURCES_OBFU 0x44电驴的Socket网络通信部分写的超级搞笑,听我慢慢道来首先EMSocket.h这个类是他的业务通信类可以清楚的看到他的协议头部分是个#define PACKET_HEADER_SIZE 6字节看他的接收是一个静态缓冲区static char GlobalReadBuffer[10*1024*1024];10M大小在接收时候大于8K的使用10M设置,小于8k的使用8Kuint32 recvbufferlimit = 2*ret;if (recvbufferlimit > (10*1024*1024)) {recvbufferlimit = (10*1024*1024);} else if (recvbufferlimit < 8192) {recvbufferlimit = 8192;}if (recvbufferlimit > m_uCurrentRecvBufferSize) {SetSockOpt(SO_RCVBUF, &recvbufferlimit, sizeof(recvbufferlimit), SOL_SOCKET);}int ilen = sizeof(int);GetSockOpt(SO_RCVBUF, &recvbufferlimit, &ilen, SOL_SOCKET);发送的时候Send(1300, 0, true);以1300MTU发送.然后在谈一下他的爷爷,他的爸爸CEncryptedStreamSocket先略去不讲class CEncryptedStreamSocket : public CAsyncSocketEx讲CAsyncSocketEx这个可是电驴最核心的通信类,他直接继承于MFC的祖宗CObject大家注意我这里会讲到电驴SOCKET的命脉所在,这是在整个互联网上还没有人讲的,我最先发布电驴的网络控制是在每一个CAsyncSocketEx中包含了一个窗口句柄,利用这个窗口来派发所有的socket通信控制这是他的SOCKETstruct t_AsyncSocketExData{SOCKET hSocket; //Socket handleint nSocketIndex; //Index of socket, required by CAsyncSocketExHelperWindow} m_SocketData;这是他的那个消息窗口struct t_AsyncSocketExThreadData{CAsyncSocketExHelperWindow *m_pHelperWindow;int nInstanceCount;DWORD nThreadId;} *m_pLocalAsyncSocketExThreadData;这是包含所有窗口句柄的链表//List of the data structures for all threadsstatic struct t_AsyncSocketExThreadDataList{t_AsyncSocketExThreadDataList *pNext;t_AsyncSocketExThreadData *pThreadData;} *m_spAsyncSocketExThreadDataList;然后大家去AsyncSocketEx.cpp中看class CAsyncSocketExHelperWindow的类实现吧,他的所有的SOCKET行为都在这里了.当然这只是通信的开始,后续代码分析我会在今后的博客中为大家见讲解。