电骡服务器列表（Emule电骡工作原理浅析）
电骡服务器列表（Emule电骡工作原理浅析）
一.概述
Emule是建立在p2p技术上的文件共享软件。它与传统文件共享的区别是：
共享文件不是在集中的服务器上等待用户端来下载，而是分散在所有参与者的硬盘上。所有参与者组成一个虚拟网络，每个用户端都可以从这个虚拟网络里的任何一个客户端的机器里下载文件。同时每个客户也可以把自己的文件共享给任何其他客户。 在Emule体系里有一些服务器，不过这些服务器不再存放文件，而是存放这些共享文件的目录或地址。每个用户端从服务器处得到或搜索到共享文件的地址，然后自动从别的客户端处进行下载，参与的客户端越多，下载的速度越快。Emule建立于多点文件传输协议之上。一个Emule网络由服务器端和客户端两部分组成。服务器端是客户端连接的、为了搜索和查找可以下载用户的桥梁。服务器列表像电话本一样排列，客户通过浏览它而获取它需要的文件所有者的客户端信息。在真正的文件下载过程中，没有下载文件通过服务器端。其体系结构如下图所示：
图1 Emule体系结构
Searching：每一个客户端连接到一个服务器作为他的主服务器。在连接时，由客户端告诉主服务器他share了那些文件，以及IP地址等其他信息。所以每一个服务器会记录所有登陆到他服务器上的以上信息。在本服务器搜索时，它会通过匹配记录的已知以上信息把查找结果反馈给搜索的客户端。当一个客户在搜索列表中选取了所需要的文件并开始下载后，Emule会记录下这个文件的大小，文件名以及另一个根据文件内容hash出的一个特殊值。Emule得到了这个信息后，会向所有添加的服务器发出请求，要求得到有相同hash值的文件。而服务器则返回持有这个文件的用户信息。
Downloading：当客户端选择了一个文件下载时，它首先收集一个拥有该文档的客户端的列表。它会先行查询主服务器所有登陆用户他们是否拥有该文件。然后再连接和查选其他服务器的登陆用户所拥有该文件的客户端列表。一旦它找到拥有该文件的其他客户端，它将请求每个客户端发送这个文件的不同片。直至最后文件由这个不同的片组装成一个完整的文件。 在查找到下载源(其他客户端)后，下载就是客户端和客户端通过P2P进行直接对话了。期间没有数据流通过服务器。一个emule client可能会使用很多的tcp连接与其他client连接来彼此上传或下载数据.当下载一个文件时,client可能同时连接上许多不同的client,从它们那里获得该文件的不同片段.即使一个client没有下载完一个文件,他也能在下载的同时将已下载部分的片断upload给其他client.emule中的server使用一个内置的数据库来存储clients及其拥有文件的信息,它本身并不存放要下载或上传的文件,而是对clients拥有的众多文件起一个中央索引定位的作用.
二 .Client/Server TCP communication
2．1 Connection establishment
在Emule体系结构中，一个client只能和一台server建立连接,建立之后server赋予client一个client id,用于在以后的会话期间唯一的标识这个client. Client/server的这一tcp连接在client的整个会话期间始终存在.Client id分high id 和low id两种。当一个client不能接受外来连接时,它就被赋予一个low id.一种可能是client在NAT或者proxy server后面.如果一台机器能让其他client自由连接它本机的tcp port(default is 4662),那么它就被赋予一个high id.
High id的计算公式：
假设ip为x.y.z.w,
Id=x+2^8*y+2^16*z+2^24*w
而Low id 总是小于16777216(0x1000000)。
下面分别阐述High id和low id的client与server的连接过程：
High id连接过程:
Client建立一个和server的tcp连接,发送login message过去,server使用第二个tcp连接与client进行handshake,其目的是为了检验client是否有能力接受其他clients发起的连接.当完成client-to-client握手之后,server关闭第二个连接,再发送个client一个id change 消息来完成client-server handshake.其过程如下图所示：
图2 high id login sequence
Low id连接过程：Client同样与server建立连接,但是当server与client建立连接时将失败,通常发回给client一个消息,形如”Waring you have a lowed.Please review your network config”.最后server仍旧发送一个id change message.如下图所示：
图3 low id login sequence
注意，Emule中的server配置有两个限制:hard limit和soft limit;
其中Hard limit >= soft limit.当连接一个server的clients 数达到soft limit时,server停止接受low id client的连接;当达到hard limits时,server停止对任何client的连接.此时的连接过程如下图所示：
图 4 Reject Session sequence
2.2Connection starup message exchange：
当cs连接成功建立之后,client与server彼此交换一些setup message.client向server提供一个list,记录了自己shared的文件,然后要求更新server list.于是server发回它的状态和版本信息,以及自己维护的众所周知的server list.最后client就会要求下载某些文件,此时server就会查找哪些其他的clients拥有这个被请求的文件,然后将这些clients的列表发回给请求的client.如下图：
图3 Connection starup sequence
Callback 机制：
设计这一机制的目的在于克服low id client不能接受外来连接的缺点。其实现原理很简单：假设a和b连接上同一个server,a需要一个文件,这个文件存放在b上,但b拥有一个low id.于是a发送一个callback request给server,要求server通知b主动连接a..server于是给b发送一个callback request,为其提供了a的ip和port,之后b就能与a建立连接,而不需要server的干预了.
图4 callback sequence
三.Client/Server UDP communication
3.1 Server keep alive and status information
Client周期性的对自己server list上的server进行状态检查.这是通过client发送UDP server status request消息和UDP server description request这两个消息来完成的. 其中server status request中包括一个随机数.这个数在server的reply中被回射.倘若回射值与原来的不一致,则server的reply中的信息被丢弃.client维护一个计数器,每次status request发送出去时计数器加一,从server收到的任何消息都重置这个计数器.当这个计数器的值达到一个预先配置的上限时,server被认为不可用,从client的server list中删除. Server statusrequest的reply包括当前用户数和server中索引的文件以及server的soft/hard
Limits.而Server description reply包括server name和一个短的描述性字符串。整个过程如下图所示：
.
图5 UDP keep alive sequence
3．2 Enhanced File search
Emule的client能使用UDP服务来增强其文件搜索功能。当一个client试图下载一个文件,但是他得到的sources数目小于一个可配置的值（默认是100）的时候,它就会周期性的向自己server list里的所有server发送UDP get sources packet来试图找到更多的拥有此文件的sources。
四.Client To Client TCP Communication
在client与server成功建立连接,并且从server那里取得拥有自己想要的文件的sources信息之后,clinet就需要与source列表中其他的client交互，即分别与这些source都建立起一个tcp 连接.当一个连接上在某个时间段内(默认是40秒)之内套接字没有事件到来(没有读或写)或者任何一个client端关闭了连接时,该tcp连接就失效.
4．1 Initial handshake
这种握手是对称的:两端都向对方发送同样的信息.信息中包括identification,version和capabilities information.发送的信息有两种类型，一种是hello message，这实际上是eDonkey协议的一部分，另外一种是Emule info message,这部分是Emule协议自己特有的部分。握手过程如图：
图6 eMule client initial handshake
4．2 The Credit System
设计Credit system的目的是为了鼓励用户彼此共享更多的文件。当一个client为他的peer上传文件时,正在下载的peer根据接收到的数据量来更新credit值.这个credit并不是全局的.一个特定的传输过程对应一个特定的credit值,这个值被正在下载的client保存,只有当为这个client提供上传的peer转而要求从client上面下载文件的时候,这个credit才起作用.
Credit取下列值的最小值:
1. uploaded_total*2/downloaded_total
当downloaded_total为0时,整个表达式设为10.
2. sqrt(uploaded_total+2):
当uploaded_total< 1 MB 时,这个表达式设为1.
注意，credit的取值范围：1<=credit<=10.
4.3 Requesting files
Client A 发送一个file request message,其后紧跟一个requested file id message.Client B
对于这两个消息的回复如下:前者以一个file request answer消息回复,后者以一个file status message作为应答.该协议还可被扩展为：在这个消息序列中增添两条新的消息：source request和source answer。通过这两条消息，就能把B的sources列表发送给A，同时，B也能把自己已经下载了的文件片断发送给A。如果B并没有A所请求的文件，B就不发送file request answer消息，取而代之的是file not found message。
图7 File request failure
4．4 Queue Management
假如Client A向Client B请求一个文件,B拥有,但是其上传队列非空,这意味着当前存在其他client已经与Client B握手完毕并正在下载文件,于是B将A加入到它的upload队列,并返回一个queue ranking message,这条消息内包含了A在B的upload队列中的位置.
对于upload文件的client B来说,它自己维护一个upload队列.在队列中每个client的优先级以client在队列中的逗留时间及一个优先级变量来决定.在队列头的client具有最高的score.score的计算公式：
Score=rating*seconds_in_the_queue/100.
假如该client被定义为friend,则socre为无穷大.Rating一般被初始化为100.
Rating的变动取决于下列情况:
1. 正在下载用户的 credit值(1~10);
2. 上传文件的优先级(0.2~1.8)
当队列中一个client的score超过了某个正在下载的client时，正在下载文件
的client就被抢占。为了避免一个client刚刚开始下载就被别的client所抢占,emule将一个刚开始下载的client的rating设置为200,并维持15分钟. 当a到达b的upload队列队首时,b连接a,进行handshake等初始化工作,然后发送一个accept upload request message.此时a有两种选择:或者发送一个request parts message来开始下载文件,或者选择取消(此时它可能已经在其他sources处下载到了想要的文件片断).
4．5 Data Transfer
当一个File request answer消息被发送之后，文件块的传输就开始了。试图下载的Client A发送一个start upload request，而Client B以accept upload request回复。然后A就开始逐一请求文件块，而B开始发送A所请求的块。
图 8 文件传输
4．6 块的选择策略
在Emule中，每个文件被分成大小为9.28MB的一系列块，每个块又被分成180kb大小的子片断。下载时使用下面的片断选择策略：
1．Sources之间拥有的最少的片断应该尽可能快的下载，这样一旦下载结束，该client就能成为一个新的可用的source。
2．那些用来预览的子片断（比如first，last块），或者用于文件校验的块（如movie，
mp3）。
3．一个块中如果有部分子片断被下载,那么其他的子片断应该尽可能快的被下载,而不是又去挑选一个新的块来下载
4．7 查看共享文件及文件夹
两个client之间通过消息传递来查看彼此共享的文件和文件夹。对于查看文件，使用view shared files和view shared files answer这对消息来完成。当一个client试图隐藏自己共享的文件列表时，它发送的view shared file answer消息中包含0个文件，而不是采取发送一个denied消息通知对方这种方式。如图所示：
图 9 View shared files
而对于查看文件夹来说，client向另一端发请求以查看共享的文件夹列表，然后收到另一端回复过来的共享文件夹列表。然后对于该回复消息包含的列表中的每一个文件夹，都发送一个view shared folder content消息过去。这个消息的回复是一个content list。
图10 View shared folders
五．Client To Client UDP Communication
在Emule中，client使用UDP协议周期性地查询自己在另一端的client的队列中的位置。其实现方法是用一种简单的“请求－回复”机制，以一个Re-ask file 消息来初始化。对于这一消息，有三种可能的回复：
1． Queue rank：表明该client在其sender队列中的位置；
2． Queue Full：表明sender的队列已满；
3． File not found：sender并没有该client请求的文件；
Re-ask消息以20分钟一次的间隔发送往那些已经将它加入到下载队列的所有sender去。
图 11 Re-ask file message
六．Message Encoding
所有的消息都是以little-endian方式编码.
所有的消息都具有一个6字节的头部:
头部结构如下:
1字节的协议id:edonkey为0xe3,emule为0xc5;
4字节的消息大小,该大小不包含头部,假如消息内不含任何负荷(payload),则该字段为0;
1字节的消息类型字段,是一个独一无二的消息id.
Message tag:
Tags是一种形如（Type，length，value）的结构，用于给emule 中的各种消息追加一些可选的额外信息.
每个tag有4个域:
1. type:1个字节的整数
2. name:可以是变长的字符串或者1个字节的整数;
3. value:可以是4字节整数或者4字节浮点数或者是可变长的字符串
4. 特别字段域:1字节的整数
希望看了这些介绍之后，大家能对Emul的工作原理有最基本的认识，谢谢。
