Protocol)是一种分发文件的协议

1、VDUP协议VDUP（Virus Database Update Protocol）是一种分发文件的协议，它专门用于病毒库的升级。它通过URL来识别内容，并且可以无缝的和web进行交互。它基于HTTP协议，它的优势是：如果有多个下载者并发的下载同一个文件，那么，每个下载者也同时为其它下载者上传文件，这样，文件源可以支持大量的用户进行下载，而只带来适当的负载的增长。 一个VDUP文件分布系统由下列实体组成：1、一个或多个病毒库升级服务器2、一组增量更新的病毒库文件“元信息”文件3、终端下载者要提供文件共享，那么一台服务器需要执行以下步骤：1、运行一个下载管理器程序2、根据最新发布的病毒库文件来生

2、成增量更新的“元信息”文件（.xml）。3、将“元信息”文件发布到web服务器上4、运行一个数据库程序5、运行一个客户端程序要开始下载文件，那么终端用户执行以下步骤：1、安装客户端程序2、客户端程序访问病毒库升级服务器3、对比版本号，获取服务器端增量更新的 “元信息”文件，写入本地“元信息”文件4、从服务器获得peers列表5、根据peers列表与其他peers互联，相互上传和下载文件6、下载结束后，提供限时或限量上传服务。各个部分之间的连通性如下：服务器负责提供一组增量更新的元信息文件。下载管理器程序从所有下载者处接收信息，实时写入数据库中，并查询数据库，返回给它们一个peers列表。这种交

3、互是通过HTTP或HTTPS协议来完成的。下载者周期性的向下载管理器登记，使得下载管理器能了解它们的进度；下载者之间通过直接连接进行数据的上传和下载。这种连接使用的是VDUP对等协议，它基于TCP。服务器只负责上传，从不下载，因为它已经拥有了完整的文件。服务器是必须的。元文件是采用XML格式，包括以下关键字：UpdateDate：该版本病毒库文件的发布时间VerNum：病毒库版本号PieceNum：文件分块数PieceLength：块长，对应文件分割成的块的字节数。出于传输需要，文件被分割成大小相等的块，除了最后一块可能会被文件尾截断而小一些（剩下的大小不足一个块长）。块长是2的权值（VDUP

4、协议默认值是8K，2的13次幂）。PieceHash：对应一个字符串，此字符串长度是20的倍数。它可以再分成每20字节一段的多个字符串，分别对应每个块的SHA1校验码（hash）。ComponentID：杀毒软件名，可以用于区分不同的杀毒软件产品。UpdateType：文件类型，可以用于区分升级的文件是病毒库文件，还是程序升级文件等等。LocalPath：文件保存路径Filename：文件名FileSize：文件大小，以字节为单位。FileHash：一个20字节长的字符串，对应文件的SHA1校验码。发送给下载管理器的GET请求，分为用户验证和状态信息反馈两种。用户验证GET请求包含以下关键字：

5、Ver_num：下载者本地病毒库的版本号。用于和服务器进行版本对比，确认是否要更新病毒库。Prod_sn：下载者的杀毒软件序列号，用于验证用户的升级权限。IP：下载者的ip地址（或DNS主机名）Port：下载者所监听的端口。下载者通常在在 10881 端口上监听，如果该端口被占用，那么会一直尝试到10889，如果都被占用，那么就放弃监听。状态信息反馈GET请求包含以下关键字：Peer_id：一个20字节长的字符串，是下载管理器在下载者通过正版验证后，自动分配给下载者的一个ID号。Prod_sn：下载者的杀毒软件序列号，用于验证用户的升级权限。Uploaded：目前总上传量，编码为十进制ASCI

6、I码。Downloaded：目前总下载量，编码为十进制ASCII码。Left：还要下载的字节数，编码为十进制ASCII码。注意，这个值不能根据文件长度和已下载数据大小计算出来，因为很可能是断点续传，如果因为检查文件完整性失败而必须重新下载的时候，这也提供了一个机会。Event：状态信息关键字，值是started、completed、stopped、peers、delete之一。在下载刚开始的时候，该值被设置为started，在下载完成之后，设置为completed。如果下载者停止了下载，那么该值设置为stopped。如果下载者要再次申请Peers列表，那么该值设置为peers。如果下载者完成了

7、额定的上传量或者上传时间，想退出升级，那么该值设置为delete。下载管理器根据该关键字的值来更新Peers列表里各Peer的状态或者再次下发Peers列表。如果下载管理器回应中有关键值failure reason（失败原因），则其内容应是易读懂的字符串信息，用来解释升级失败的原因，比如“已经是最新版本，无需升级”、“序列号已过期”、“序列号已被列入黑名单”等等。否则，下载管理器的回应必须有三个关键值：Interval（间隔）：对应下载者定期发出请求的间隔秒数，要求下载者定期向下载管理器发送状态信息，默认设置30秒。Peer_id：下载管理器分配给下载者的ID号，用于标记下载者的身份。Peer

8、s：一个包含字典的列表，每个字典对应一个peer，里面包含关键值Peer_id、IP和Port，分别对应peer的用户ID、IP地址或DNS主机名的字符串以及端口号。（下载者通过 HTTP 的GET 命令来向下载管理器发送升级请求，下载管理器响应一个peers列表）VDUP对等协议基于TCP。对等的两个连接是对称的，消息在两个方向上同样的传递，数据也可以在任何一个方向上流动。一旦某个peer下载完了一个块，并且也检查了它的完整性，那么它就向它所有的peers宣布它拥有了这个块。连接的两个终端有2个状态指标，被阻塞（choking）与否，被关注（interested）与否。阻塞（choking）

9、是通知对方，没有数据可以发送，除非unchoking发生。一旦一端状态变为关注（interested），而另一端变为非阻塞（unchoking），那么数据传输就开始了。当数据传输时，下载者马上将好多份对块的请求排成队列，以获得较好的TCP表现（这叫“流水作业”）。另一方面，不能被马上写入TCP缓冲区的请求要在内存里排成队列，而不是在一个应用程序级的网络缓冲区里，一旦阻塞出现，丢弃所有这些请求。对等协议由一个握手开始，后面是循环的消息流，每个消息的前面，都有一个十进制数字来表示消息的长度。握手的过程首先是先发送30，然后发送字符串“Virus Database Update Protocol”。

10、30就是“Virus Database Update Protocol”的长度。后续的所有的整数，都采用big-endian 来编码为4个字节所有送入协议的整型数据都编码为4字节高端字节序（four bytes big-endian）。在协议名称之后，是8个保留的字节，这些字节当前都设置为0。接下来是20个字节的 Peer_id。它包含在下载管理器回应下载者的peers列表中。这就是握手过程。接下来就是以消息长度开始的消息流，这是可选的。长度为0 的消息，用于保持连接的活动状态，被忽略。通常每隔30秒发送一个这样的消息。 其它类型的消息，都有一个字节长的消息类型，可能的值如下：0-阻塞1-通畅

11、2-被关注3-不被关注4-已有5-比特组6-请求7-块8-取消“阻塞（choke）”、“通畅（unchoke）”、“被关注（interested）”和“不被关注（not interested）”类信息没有荷载。“比特组（bitfield）”仅作为首信息发出。它的数据实际是一个位图，如果下载者已经发送了某个片断，那么对应的位置1，否则置0。下载者如果一个片断也没有，可以忽略这个消息。首字节高位到低位对应索引序号0-7，以此类推，第二字节对应索引序号8-15，等等。尾部的剩余的比特位设为0。“已有（have）”类型的消息，后面的数据是一个简单的数字，它是下载者刚刚下载完并检查过完整性的块的索引序号

12、。“请求（request）”类型的消息，后面包含索引号、开始位置和长度，后两者是偏移字节数。长度一般是2的权值，除非被文件尾截断。现行一般是2的15次幂，并且关闭请求中长度大于2的17次幂的连接。 “取消（cancel）”类型的消息，它的数据和“请求（request）”类型的消息一样。它通常在下载接近完成即“最后阶段（endgame mode）”发出。在一次下载接近完成的时候，最后的几个块需要很长时间才能下载完。为了确保最后几个块尽快下载完，它向所有的peers发送下载请求。为避免低效，一旦某个块下载完成，它就其它peers发送“取消（cancel）”消息。 “块（piece）”类型的消息，包

13、含一个索引号、开始位置和实际的块数据。它和“请求（request）”消息是相关的。当传输速度很慢或“阻塞”“通畅”类信息快速连续发出或两者同时发生，可能会下载到一个不需要的块。片段选择算法Seed维护两个列表，一个是存放未被请求的片段标记的列表List1，在片段还未分配之前，所有的片段标记都存放到列表List1中；另一个是存放已被请求的片段标记的列表List2。当第一个Peer来请求第一个片段时，Seed从List1中随机选择一个片段发送给该Peer，然后把该片段标记从List1中删除，写入List2中。再有Peer来请求第一个片段时，Seed从List1中剩余的片段中又随机选择一个发送出去，

14、然后修改List1与List2的内容。以此类推，若片段有n个，那么当有n个Peers来请求片段时，Seed就已经把所有片段都分发到了P2P网络上。阻塞算法阻塞算法是一种临时的拒绝上传策略，一个好的阻塞算法应该利用所有可用的资源，为所有Peers提供一致可靠的下载速率，并适当惩罚那些只下载而不上传的Peers。Peer对那些向它提供上传服务的Peers给予同样的回报，目的是希望在任何时候都有若干个连接正在进行着双向传输。从技术层面上说，每个Peer一直与固定数量的其它 Peers 保持疏通（通常是4个），为了判断哪些Peers应该保持疏通，系统每隔10秒计算一次哪个Peer需要被阻塞，然后将这种

15、状态保持到下一个10秒。10秒已经足够使得TCP来调整它的传输性能到最大。另外有可能存在空闲的连接比当前正使用的连接更好的情况，为了发现这种情况，在任何时候，每个Peer都拥有一个称为“optimistic unchoking”的连接，这个连接总是保持疏通状态，而不管它的下载速率是怎样。系统每隔30秒重新计算一次哪个连接应该是“optimistic unchoking”。30秒足以让上载能力达到最大，下载能力也相应的达到最大。某些情况下，一个Peer可能被它所有的Peers都阻塞了，这种情况下，它将会保持较低的下载速率直到通过“optimistic unchoking”找到更好的Peers。为了减轻这种问题，如果一段时间过后，