下载引擎的设计与实现（共8篇）
下载引擎的设计与实现 篇1
0 引言
高速网络在提供便利的同时也带来很多安全问题,数据流管理系统是目前解决网络安全问题最主要的防御手段[1]。 基于软件的防御系统可以满足普通用户的应用需求, 但是对于网络传输速度达到G bit/s的企业级网络来说,系统容易出现丢包、漏检的情况,且较大资源占用量也大大影响了整体系统的性能。 因此设计专用的硬件匹配引擎成为防御系统的发展趋势。
随着网络中恶意数据的种类急剧增加, 使得将匹配的特征码全部存到内部存储器成本也越来越高,但若使用外存又将大大降低系统吞吐率。 Bloom Filter ( 布鲁姆过滤器) 作为一种精简的信息表示方案, 在实现高速的数据查找的同时可以降低存储资源的消耗。
基于标准Bloom Filter和改进Bloom Filter[2,3,4,5,6,7]的匹配方案有很多,例如文献[8]使用双Hash的方案,利用FPGA中的双端口存储器实现特征码Hash值的存储和查找,同时可以实现数据的在线更新, 但是双Hash方案没有解决Bloom Filter假阳性误判(即不属于集合中的元素而误判为属于集合中)[9]问题,较高的错误率将大大降低系统的可靠性。 文献[10]提出了一个基于Bloom Filter和位拆分状态机的多模式分步匹配引擎设计方案,可以实现数据流的高速精确检测,方案的精确匹配部分使用选择位状态机, 在检测时依然占用较大内存。 文献[11] 使用窗口折叠Bloom Filter与软件结合的设计方案, 方案提高了系统的资源利用率, 但系统匹配精度不高, 同时软件低频率也大大影响了系统的吞吐率。 文献[12]构造了一种特殊结构的Bloom Filter, 其向量空间存储值并非0或1,而是由计数器和编码值两部分组成, 在匹配中, 通过这两部分值可以恢复匹配位置存储的数据,解决了传统Bloom Filter假阳性误判问题, 该方案仅适用于匹配
本文将Bloom Filter与FPGA系统软核相结合, 设计了一种资源消耗少、匹配速度快的软硬核结合的分步匹配引擎方案。 在系统部分匹配中, 文本基于标准Bloom Filter原理, 设计了FIBF ( Finite - Input Bloom Filter ) , FIBF对特征码长度不进行区分,通过对固定长度特征前缀的高速扫描,过滤出可疑数据;而后, 使用FPGA软核微处理Nios II[13]和片外存储器SDRAM对数据进行精确扫描。
1 Bloom Filter原理
Bloom Filter可以实现高速数据传输下的数据查找,算法实质是将集合中的数据通过K个Hash函数映射到位串向量中。 与传统的Hash表的链式存储结构相比,Bloom Filter过滤器的Hash表查找快, 占用的存储空间大小与集合规模和集合中数据位宽无关,仅与映射后向量的位数相关。
Bloom Filter数据结构如图1 所示。 设数据集合C ={ c1, c2, … , cn} , 其n个元素通过k个相互独立Hash函数h1, h2, … , hk映射到长度为m的位串向量V中,Hash函数的取值范围为{0,1,… ,m-1}。 对字符串c′进行检测,若输出值为1, 则元素c′是可能需要查找的字符串, 否则肯定不是。
Bloom Filter存在假阳性误判, 因而, 在应用中需要对查询误判率进行评估, 设计出符合应用需求的Bloom Filter[9]。
假设Hash函数取值服从均匀分布,则当集合中所有元素都映射完毕后,向量V中任意一位为0 的概率p′为:
不属于集合中的元素被误判属于的概率(即误判率)f为:
式(2)两侧对k进行求导,令导数为0,得:
当k=kmin时,p=p′=1/2, 此时元素出现误判的最小概率fmin为:
在实际应用中k必须是整数并且要尽量小, 因此,在计算Hash个数时取。 在集合元素个数和向量空间大小已知的情况下, 可以计算出最小k值。 如图2 所示是取m=16 384、n=2 000 时,误判率f与Hash个数的关系。 当k = 6 时, f取最小值fmin= f ( 16 384 ,2 000 , 8 ) = 0 . 019 6 。
若设计时对k个Hash函数,每个Hash函数使用独立的向量,则向量中某比特位为1的概率q=n /m,此时元素出现误判的概率为:
取n=2 000,f′=fmin= 0 . 019 6 , 如图3 所示, 图中单个向量空间大小m随着k成指数递减, 但是所需的存储器总量m′随k成 “√”变化,当Hash函数个数k =4 时所需的存储空间总量最小。
2 高效过滤器设计
2 . 1 过滤系统结构
病毒过滤系统的总体设计模型如图4 所示, 系统由硬件系统和MPU系统两个部分组成。 系统的工作流程如下:
( 1 ) 软件系统抓取数据包或者读入磁盘信息, 此过程由软件扫描引擎来完成。 例如Clam AV扫描引擎, 其将文件数据读入, 对文件进行有效性扫描, 这个过程主要用于检测文件大小是否越界、 文件是否可以打开, 然后将有效数据输出。
( 2 ) 部分匹配引擎对输入的文本数据进行高速扫描,此过程由硬件过滤系统完成。 硬件过滤系统将数据流与特征码前缀进行匹配,将匹配的可疑数据经指针产生器处理后输入到精确匹配模块。
( 3 ) 精确匹配引擎对可疑数据进行深度过滤, 此过程由MPU完成。 MPU根据指针产生器给出的地址读取特征码,使用KMP算法对文本进行匹配,若前缀匹配失败则匹配产生虚警,精确匹配结束。
2 . 2 FIBF设计
FIBF由c个移位寄存器和一个Bloom Filter组成,如图5。 数据由输入端口输入到移位寄存器中, 移位寄存器在每个时钟上升沿都要进行一次右移操作,同时将寄存器中的数据输出到Bloom Filter中。
FIBF与标准Bloom Filter引擎设计, 其每个结构中只使用一个Bloom Filter,检测特定长度8c bit的文本信息。N个FIBF并行操作可以同时查找N × 8c bit信息, 图6 所示是使用3 个FIBF构成的部分匹配引擎模型,每个FIBF扫描6 B信息。
在Bloom Filter设计中, 选择Hash函数是非常重要的一个环节。 在本设计中,Hash函数的选择遵循以下两条原则:
( 1 ) Hash函数要适合硬件实现。 硬件电路具有强大的逻辑运算能力,因此在算法选取时要尽量多使用逻辑运算,降低算术运算量。
( 2 ) 输出结果要与每一比特位相关, 以降低Hash冲突的概率。
文献[14] 给出的Hash函数构造方案H3很适合硬件实现。 对于有a个比特的字符串S={s1, s2, … , sa} , 通过H3算法构造的Hash函数可以表示为:
式中, “·” 为与门, “ ⊕ ” 为异或门,q表示一个a×a′的随机数阵列。 矩阵行数a对应输入字符串的比特位数,列数a′对应Hash值的位数,a′的值由Bloom Filter中向量空间大小决定。
2 . 3 指针产生器设计
当3 -FIBF部分匹配引擎发生匹配时,FIBF2 和FIBF3 并不能确定已匹配的前缀是其对应子串的前缀,即在匹配中会出现排列组合的情况, 这将大大增加匹配的误判率。 而精确匹配耗时多效率低,若产生的误判率过高,精确匹配逐一匹配特征码将大大影响整个系统的吞吐率。 指针产生器的设计可以检测匹配的多个子串是否可能对应于某一特征码,同时产生精确匹配中特征码的地址,提升精确匹配效率。 指针产生器设计如图7所示。
指针产生器从缓存中取出w bit的可疑数据, 经过一次Hash变换得到v bit的Hash值,以此Hash值作为地址到存储器中查找可疑数据对应特征码在SDRAM中的地址。 若查找的地址空间的数据为全 “1”, 则表示匹配产生虚警。
例如,设特征库集合中元素个数为n=7,使用2-FIBF扫描数据,每个FIBF扫描2 B, 则匹配的前缀长度为4 B。经Hash函数H(b)=b Q[14],n个前缀经Hash运算后产生的地址、指针对应关系如图8 所示。 b是由缓存数据表示的1×16 向量,Q是一个16×4 的随机向量。
对于特征编号为 “1” 的特征, 其前缀为 “21b8”, 经Hash函数运算后得到的Hash值为 “ 1010 ” , 把Hash值作为地址到存储器中查找对应的位置的数据,对应数据为精确匹配中特征码存储的地址。 若输入数据为 “2100”,在FIBF检测中输出发生匹配, 此时指针查找器读取缓存中的 “2100”, 经Hash变换后产生Hash值 “1011”, 对应的特征地址为 “111”,可判断产生虚警。 若输入数据为2150 , 在FIBF检测中同样发生匹配, 但是经指针查找器输出的地址数据为 “101”,未排除虚警,但是由于给出的地址对应的特征前缀为 “5055”, 在精确匹配中, 首字母匹配失败,则直接结束匹配。
Hash实现多对少映射, 上边例子使用的Hash函数由H3算法构造, 当特征集合中元素数目增多, 且字符串数据随机性比较差的情况下,H3算法产生的碰撞概率比较大, 此时可以采用文献[15] 提出的多IGU (Index Generation Unit ) 并行方案。 IGU的预处理阶段首先使用特征码中的比特位构成二维数组, 数组中的数据对应特征码的地址指针。 通过对数组进行分析,选择合适的X、Y坐标的位进行异或操作, 以产生的值作为Y值, 使用Y可以唯一地确定指针。 对于少部分产生碰撞的数据,文献[15]通过设计一个额外的IGU存储器存储这些数据。
2 . 4 地址存储空间设计
Bloom Filter必须使用一定的存储空间来存储向量,设计好的存储设计方案可以提高内存利用率并提高系统吞吐率。 在模式匹配中,存储大容量的特征码数据内部存储器无法实现, 只能使用片外存储, 但是对于数据量比较小的向量, 若使用片外存储器, 不仅降低了系统频率,而且降低了内存使用率,浪费FPGA资源。
为了实现数据的快速的查询,设计中可以2个Hash函数共用双端口RAM存储器[14],也可以使用单口RAM,每个RAM对应一个Hash函数。通过实验分析,一个双端口RAM占用的资源量是一个单口RAM资源占有量的2倍多,并且双口RAM扇出比较大,延迟多,同时增加了发生虚警的概率,所以本文选择使用单口RAM进行数据存储。
3 性能实验及分析
实验选取Clam AV特征库main.db类中2 000 个特征码, 部分匹配关键字为对应特征码的12 B前缀, 可接受的误判率f =0.019 6, 根据式(5) 和图3 可计算出当k = 4 时每个FIBF所需的总存储空间最小为25 093 bit ,此时单个向量空间大小为5 019 bit, 但是由于存储器空间大小为2 的幂次方,所以k=4 时每个Hash函数的实际占用空间大小为8 192 bit, 这使得总存储空间大小增大到32 768 bit。 而取k=6,单个向量大小为3 858 bit,存储所需的存储器大小为4 096 bit, 总存储空间为24 576 bit<32 768 bit 。 引擎使用2 个FIBF并行操作, 每个FIBF检测长度为6 B。 输入本文为“ca21b8005a”检测前缀的FIBF仿真波形如图9。 数据输入以ASCII形式,向量输出为高电平表示其对应的Hash空间发生匹配,只有当所有的向量空间输出全为高电平, 输出信号 “result” 才为高电平。从图中可以看出 “21b800”为检测出的特征码前缀。
实验使用ALTERA低成本Cyclone II系列的开发平台。 第一步部分匹配,每个FIBF存储2 000 个特征码的6 B关键字需要使用6 个M4K RAM , 总的存储器消耗量为27 648 bit, 单字节输入的最大工作频率为260 MHz。指针产生器将2 000 个特征码的地址数据存储到一个12 输入、 11 输出的储存器, 使用11 个M4K 。 第二步精确匹配,全部特征码存储在外部存储器SDRAM中,匹配算法使用Nios II/f嵌入式软核, 使用4002 LE, 工作频率为100 MHz 。
实验中系统最大吞吐率为3.12 Gb/s,设存储器利用率(MUC)为每个特征字节需要的存储器大小, 单个FIBF的
为了与其他算法相比较, 使用标准化吞吐率Th/MUC[16], 结果如表1 所示, Th表示引擎的吞吐率单位是Gb / s , Pattern表示存储的特征码的数目, Tool表示使用的硬件器件。
4 结论
本文提出了一种结合了Bloom Filter以及FPGA软硬核的高效匹配引擎设计方案。 方案使用分步匹配的方法, 使用Bloom Filter结合硬件高度并行的特点一次过滤掉大部分正常数据, 而后系统MUP通过指针定位精确匹配特征码在SDRAM中的位置, 实现快速的精确匹配。 通过流水线的方式,设置缓存空间,将软硬件模块相连接,使系统可以实现高速网络下的数据精确检测。 实验中2-FIBF过滤系统吞吐率达到3.12 Gb/s, 完全可以满足千兆网络的需求, 通过多个FIBF并行同时增大FIBF检测窗口大小, 可以实现更高传输速率网络中的数据检测。
摘要：针对软件模式匹配引擎速度慢、占用系统资源大的问题,提出了一种基于Bloom Filter的FIBF结构,结合FPGA NIOSII微处理器(MUP),设计了软硬核相结合的匹配引擎方案。引擎通过FIBF过滤过滤掉大部分正常数据,将过滤出的可疑字符串输入到NIOSII软核进行精确匹配,两者之间通过一个指针产生器连接,整个系统以流水线方式工作。FIBF结构资源消耗低,n-FIBF并行处理,系统引擎可以达到较高的吞吐率。实验表明,在使用相同资源的情况下,本方案系统吞吐率要优于其他算法。
关键词：FIBF,指针产生器,NIOSII微处理器,流水线方式
下载引擎的设计与实现 篇2
关键词：二分图；邻接矩阵；聚类；数据挖掘；搜索引擎
中图分类号：TP311.1 文献标识码：A
1 引言（Introduction）
众所周知，关键词数量越多，单个词越能清晰表达查询需求，搜索引擎就越能准确计算网页相关度，用户就越能准确得到所希望的查询结果。然而绝大多数用户在使用搜索引擎时，输入的关键词都少于三个，且很多情况下，关键词不能正确表达用户的查询需求，使得查询结果不尽如人意。本文采用概念聚类的方法，设计个性化搜索引擎，针对Web数据挖掘，能很大程度地提高搜索的准确率。
聚类就是将一个对象的集合通过某种算法分成几个类，分类后不同的类中的对象是不相似的，同一个类中的对象是相似的[1]。查询聚类是为了将相似需求的查询表达式聚为一类，从中选取关键词个数较多的作为这一类需求的表达，这样对查询表达式进行扩充，从而提高搜索的准确率[2]。
2 二分图及其存储（Bipartite graph and its storage）
设计中，联合考虑关键词和对应文本，即根据关键词所形成的词簇信息对文本进行聚类，聚类过程的数据结构定义如下：
定义1：设G=
对G采用实现存储，设eij为边[i，j]的权值，则记
（1）
为G的邻接矩阵。
3 聚类算法（Clustering algorithm）
使用中的很多搜索引擎在计算查询关键词与网页的相关度时，是根据网页内包含关键词的个数来定的，由于用户输入的关键词比较短，且一般不超过三个，加上有的关键词有歧义，而且由于网页内容的多样性，导致查询到的网页与用户的需求存在较大的差距。除了可以采用锚文本来对网页内容进行补充和描述的方法来提高查询准确率外，另一种有效的方法就是利用用户的点击率作为网页内容的补充了。从搜索引擎的日志中获取的用户点击数据可以在一定程度上反应关键词与页面之间联系，可以作为相关度计算的加权参数。
基于二分图的聚类算法有两种：基于超链接的聚类算法和基于概念的聚类算法。基于超链接的算法中，每当用户点击一个链接，就认为该链接和关键词是相关的，认为只要两个不同的关键词有相同的链接就将两个关键词聚类在一起，这样，由于关键词的语义多样性，很可能将语义不同的关键词进行聚类，加上Internet上很少有相同的链接，两个随机关键词被用户选择相同链接的概率仅为6.38*10-5，所以基于超链接的算法存在很大的缺陷[3]。
选择采用基于概念的聚类算法，对于设计一个高准确率的Web数据挖掘的个性化的搜索引擎系统，能达到更好的效果。构造概念聚类的二分图模型如下：
把所有的查询构造成顶点向量集合Q，关键词涉及的概念构造成顶点向量集合C，关键词与概念之间的关系构造成边集，即可得到概念聚类的二分图模型如图1所示。
例如当关键词为apple ipad、apple、apple iphone时，涉及的概念则包括ipad、fruit、iphone、product，构造的概念二分图如图2所示。
conceptual clustering
根据二分图，如果关键词涉及的概念相互重叠得越多，则关键词的相似度越高。设N（x）是节点x的邻节点的集合，N（y）是节点y的邻节点的集合，关键词的相似度按如下公式计算：
（2）
由式（2）可以看出，两个关键词涉及的概念集的交集越大，则查询的相似度越高。下面是构造二分图算法的伪代码：
4 系统模块设计（The system module design）
本系统的设计目的，是设计和实现一个为用户提供使用搜索引擎的平台，为用户提供搜索界面，并将用户输入的关键词提交给搜索引擎，再将搜索引擎的搜索结果反馈给用户。整个交互过程的数据比如查询关键词、搜索结果、用户点击的链接等数据都由该中间件收集起来并存储，为下一步的用户建模、查询聚类做准备[4]。
系统由四个主要模块组成：数据收集模块、数据库及管理模块、用户兴趣模块和查询聚类模块。系统流程分五步：数据收集、概念提取、用户建模、查询概念聚类、查询优化。系统各个模块的划分和模块之间数据传递方向如图3所示。
5 结论（Conclusion）
模拟五个用户，分别按表1输入查询关键词。其中第一二用户输入的关键词相同，但第一用户的兴趣点是apple数码产品，而第二用户的兴趣点是apple水果。
实验聚类结果如表2。结果表明，第一二用户虽然查询关键词相同，但由于兴趣点不同而被分到不同的类型中。类型0中的查询结果都与数码产品相关，而类型1中的结果都与水果相关，说明聚类结果能较好地按概念区分关键词。
实验表明，当聚类参数为0时，概念聚类的二分图中，低相关度的关键词被聚到一类，导致查准率比链接聚类查准率低；而当聚类参数较大时，概念聚类的查准率明显高于链接聚类的查准率，平衡保持在较高的范围内。
参考文献（References）
[1] 吴湖，等.两阶段联合聚类协同过滤算法[J].软件学报，2010，
21（5）：1042-1054.
[2] 马恩穹.基于Web数据挖掘的个性化搜索引擎研究[D].南京
理工大学，2012.
[3] Guandong Xu，Yanchun Zhang，LinLi.Web Content Mining[J].
Web Information Systems Engineering and Internet
Teehnologies，2011，6（2）：65-69.
[4] 王和勇，等.基于聚类和改进距离的LLE方法在数据降维中的
应用[J].计算机研究与发展，2006，43（8）：1485-1490.
作者简介：
刘典型（1973-），男，硕士，副教授.研究领域：软件，网络
技术.
刘完芳（1972-），男，硕士，副教授.研究领域：数据库.
钟 钢（1975-），男，本科，高级实验师.研究领域：软件
下载引擎的设计与实现 篇3
1 总体架构设计
图1是边缘缓存加速下载方案的总体架构,分为3层:数据准备层、数据分发层、数据下载层。
数据准备层负责将内容提供商提供的完整资源通过名为UpLoader组件上传至指定资源服务器(Cache Data Center,CDC)。
数据分发层负责将CDC中的数据以一定的分发策略分发到已部署好的边缘缓存服务器[5](i Cacher)中,同时将数据信息上报索引服务器(i Tracker)。
数据下载层负责组建P2P网络,供用户下载所需资源。
2 主要功能模块
基于边缘缓存的加速下载方案的具体实现分为5个模块:数据上传模块、中心资源服务器模块、边缘缓存服务器模块、索引服务器模块、数据下载器模块。下面逐一介绍各功能模块和所属架构层次。
2.1 数据上传模块
数据上传模块(UpLoader)属于数据准备层,负责将本地需要缓存的资源(主要为.torrent及对应的影视文件)进行分析验证后,采用扩展的FTP协议将数据上传到中心资源服务器,并在上传过程中保证数据的完整性和正确性。
2.2 中心资源服务器模块
中心资源服务器模块(Cache Data Center,CDC)属于数据准备层,负责将UpLoader上传的数据进行存储和统计,并适时将数据下发到各边缘缓存服务器上,供终端用户下载。CDC主要分为CDC Agent和CDC Server两部分。其中,CDC Agent主要负责跟UpLoader进行通讯,中转数据并对数据进行统计;CDC Server则主要负责数据的存储管理和分配,它监控所有边缘缓存服务器上内容访问情况,并定时运行内容分发策略,将内容下发到各边缘缓存服务器中。
2.3 边缘缓存服务器模块
边缘缓存服务器模块(i Cacher)属于数据分发层,是架设CDN网络时部署在网络边缘与终端用户进行数据交互的服务程序,通过一定的调度算法实现负载均衡。多个i Cacher之间通过Hadoop[6]实现一个高效的全局文件系统。各i Cacher主要负责提供下载数据给附近的各个下载终端,同时根据周围下载终端的资源需求,及时与CDC进行通讯,更新所存资源,满足各终端用户的下载需求。i Cacher的模块结构如图2所示:
2.4 索引服务器模块
索引服务器模块(i Tracker)属于数据准备层,主要负责对网内所有资源信息进行统计,如i Cacher的分布和数据缓存信息、活跃用户信息等等,指引数据下载层的用户去最近最好的i Cacher上下载所需资源。
2.5 数据下载器模块
数据下载器模块(i Downloader)属于数据下载层,采用P2P协议与i Cacher和网内其他Peers进行通讯进行数据下载。根据.torrent文件对下载数据进行检验以保证其正确性和完整性。基于P2P协议的下载过程如图3所示:
3 方案实现
结合对P2P和CDN技术的研究现状,综合考虑终端客户机的带宽资源及其在线时间不稳定等因素,本文提出:融合P2P与CDN技术,将资源分发网络分为两层,上层采用CDN技术,通过在网络边缘合理部署i Cacher,将资源从中心服务器推送到网络边缘服务器;下层应用P2P技术,以不同的i Cacher为中心,组成多个自治的、相互独立的P2P下载网络。i Cacher作为数据下载中心,为下层P2P网络中的Peer节点提供稳定、高效、高带宽的“源”。要实现这种基于边缘缓存的加速下载方案,需要解决以下几个关键问题:
3.1 P 2P与CDN网络的结合
新型网络结构如图4所示。中心服务器与索引服务器及部署的边缘服务器通过骨干网互连构成CDN,利用合适的分发策略把资源分发到网络边缘;各边缘服务器与周边的客户机组成相对独立的P2P下载网络,充分利用客户机的带宽资源。在新缓存网络中,新加入用户首先获取.torrent的种子文件,启动BT下载客户端(i Downloader),连接i Tracker获取拥有该资源片段的iCacher地址列表及正在下载同一资源的Peer地址列表。新用户得到列表后,与该地址列表中的i Cacher通讯,建立稳定下载通道。同时,根据Peer地址列表组建P2P网络,建立加速下载通道。用户通过稳定下载通道和加速下载通道获取所需资源,实现稳定、加速下载。
3.2 边缘缓存服务器的选择
i Tracker在接到一个合法客户的请求后,需要返回给该客户选择相应的i Cacher列表。根据就近原则,要使所选的i Cacher尽量靠近客户。根据IP地址的分配原理[7],IP地址前缀越匹配,距离就越近。因此,i Tracker在为客户选择i Cacher时可以依照地址前缀最长匹配原则[8]进行选择。当系统中有多个i Cacher地址相匹配时,则应综合考虑各i Cacher的负载情况及其内容缓存情况,此时应优先已缓存了该内容的i Cacher,其次考虑负载较轻的i Cacher。
3.3 终端上传激励机制
由于系统在用户终端层组建了P2P自治网络,每个用户终端(Peer)在其活跃期也可以作为下载源,将其所拥有的资源进行上传,供网内其他用户下载。当用户所需资源全部在网内时,尤其是在同一局域网内时,下载速度能成倍增加。为了鼓励加入该系统的用户上传资源,采用Tit-for-Tat算法[9]使上传速度快的用户得到较高的下载速度,并且适当的处罚只下载而不上传的Peer。这样有利于营造良好的P2P网络环境,实现数据下载的加速。
4 性能测试
本方案已于2009年由深圳某公司IPVD产品研发部作为资源缓存系统得以研发实现。性能测试主要围绕该公司的后台资源缓存系统进行。
随机选取公网上的10个.torrent文件及其对应的资源文件用作测试资源(约20Gb)。在不限制客户端网速的情况下,对客户端的下载速度(以获取每个测试资源的平均下载速度为指标)进行记录。通过对比分析可以看出,采用新方案后,客户端下载时间明显缩短,下载速度显著提高,如图5所示:
5 结束语
网络拥塞和P2P应用带来的流量泛滥问题,已经严重影响到了网络用户的下载体验。本文提出的基于边缘缓存的下载加速方案不仅能有效提高下载速度和下载稳定性,而且也能有效降低骨干网流量,提高网络性能。下一步的工作是完成新方案在电信网络中的实际应用,并对缓存系统的可扩展性和i Cacher选择及缓存资源调度的智能性作进一步研究。
摘要：针对传统网络拥塞导致网络下载速度过慢等一系列问题,文章通过对内容分发网络和P2P技术的研究,提出了一种基于边缘缓存的下载加速方案。该方案将P2P技术引入内容分发网络,利用各自优点,构建一个新型资源下载服务系统。将中心服务器上的资源推送至网络边缘,缩短了用户和资源的距离。同时,让边缘缓存服务器与邻近用户自发组建P2P下载网络,将资源更加边缘化,通过就近获取资源,提高下载速度。实验表明,该方案不仅可以有效提高下载速度,而且可以有效控制骨干网的网络流量。
关键词：P2P,CDN,边缘缓存,加速
参考文献
[1]Low S H,Paganini F,Doyle J C.Internet Congestion Control[J].IEEE Con-trol Systems Magazine,2002,22(1):28-43.
[2]Cranor CD,Green M,Kalmanek C,et al.Enhanced Streaming Services in aContent Distribution Network[J].IEEE Internet Computing,2001,5(4):66-75.
[3]周文莉,吴晓非.P2P技术综述[J].计算机工程与设计,2006,27(1):76-79.
[4]JernberJ,VlassovV,GhodsiA,HaridiS.DOH:acontent-deliverypeer-to-peernetwork[C]//European Conference on Parallel Computing,Germany,2006.
[5]宋立志,张虹.基于流媒体服务的IP网络内容分发系统的设计[J].计算机工程,2007,33(22):151-154.
[6]Bialecki A,Cafarella M,Cutting D.A Framework for Running Applicationson Large Clusters Built of Commodity Hardware[R].University of Aarhus,Technical Report:RS-05-23,2005:1-7.
[7]谢希仁.计算机网络[M].北京:电子工业出版社,2000.
[8]徐传福,陈海涛,黄遵国.基于DHT的层次式P2P资源定位模型[J].计算机工程与应用,2004,40(18):156-158.
下载引擎的设计与实现 篇4
因为Web的流行和广泛应用, 使得Internet上的很多文件的传送都是通过HTTP来完成。
1 工作原理
HTTP的工作过程如图1所示。
首先, HTTP客户端向HTTP服务器发送“HTTP请求消息”, 以获取某个特定的文件 (可能是网页类型的文件, 也可能是其他类型的文件) 。然后, HTTP服务器向HTTP客户端反馈“HTTP响应消息”, 主要包含了用户所请求的文件内容。
当HTTP客户端收到HTTP响应消息后, 从其中取出文件信息———或呈现成网页, 或提示用户保存到磁盘上。
当然, HTTP的交互操作是建立在TCP基础之上, 所以构造HTTP下载器的基本思路很简单, 首先和HTTP服务器成功建立TCP连接, 然后在此TCP连接基础上向HTTP服务器发送“HTTP请求消息”, 接着坐等“HTTP响应消息”, 收到之后, 提取出文件信息, 保存到磁盘上, 就完成了文件下载的功能。
1.1 HTTP请求消息
根据HTTP1.1的规定, 最小的HTTP请求消息仅包含请求消息头, 而且消息头中也仅包含了必需的3行数据:第1行, 请求行;第2行, HOST字段行;第3行, 空行。
一个最小的HTTP请求消息示例如图2所示, 请求下载一个名为“BaiduHelpBook.chm”的文件。
第1行是请求行, 要下载文件, 必须采用“GET”方法;“/search/BaiduHelpBook.chm”表示请求下载文件的相对路径, “HTTP/1.1”表明HTTP客户端采用的协议是HTTP, 版本号是1.1, CR/Carriage Return表示回车符;LF/Line Feed表示换行符。注意:“GET”、“相对路径”和“HTTP/1.1”之间必须用空格符隔开。
只要构造出类似图2所示的最小的HTTP1.1请求消息, 就可以达到请求下载文件的目的, 尽管典型的HTTP请求消息示例如图3所示, 有更多的选项字段。
1.2 HTTP响应消息
如果把图2所示的HTTP请求消息发送给百度的HTTP服务器, 则会得到一个典型的HTTP响应消息如图4所示, 包括消息头和消息体, 空行之上是消息头 (包括空行) ;空行之下是消息体, 也就是所请求下载文件BaiduHelpBook.chm的内容 (ASCII码形式) 。
在收到HTTP响应消息后, 只要把消息体部分保存到磁盘文件中, 就可以完成文件下载功能。但是要注意, 下载文件的请求不一定成功, 所以必须分析消息头中的状态行。状态行包括:协议及版本号、状态代码、状态短语, 如果请求成功, 则状态代码为200, 如果不成功, 则根据失败的原因会返回相应的状态代码 (具体参看IETF的RFC2616文档) 。另外字段行中Content-Length字段表明了待下载文件的大小 (以字节为单位) , 当下载文件时, 可以用它来判断是否下载完毕。
2 设计方案
文件下载器的功能较简单, 所以用户界面也并不复杂, 如图5所示。
功能1-监控剪贴板:当用户复制了文件下载链接地址时, 文件下载器会自动捕获下载地址到“下载链接”编辑框, 同时提取文件名到“文件名称”编辑框中。
功能2-选择保存目录:然后用户可以选择“浏览”按钮, 以选择文件的保存位置。
功能3-启动文件下载:最后, 用户点击“下载”按钮, 开始文件下载。
功能4-显示下载状态:在文件下载过程中, “工作状态”编辑框会显示文件下载器的实时工作状态。
功能5-显示下载进度:同时, “下载进度条”会动态显示文件下载的进度和百分比。
功能6-终止文件下载:用户也可以随时点击“终止下载”按钮, 中断文件的下载。
功能7-打开文件所在的目录:用户点击“打开所在文件夹”按钮, 打开已下载文件所在的目录。
3 实现方法
程序的框架采用Win32 SDK和Winsock2 API的开发方法。因为WinsockI/O操作可能造成程序的阻塞, 引起程序界面“死掉”, 所以采用了多线程技术。
用户界面程序线程———是HTTP文件下载器的主线程, 负责和用户进行交互。
文件下载线程———工作线程, 直接调用WinSock2的TCP编程接口函数, 实现HTTP数据的收发和保存。
程序的入口函数:
DialogBox是Windows提供的一个宏, 可以根据一个对话框资源创建一个模式对话框。
根据Windows的编程思想, “Window/窗口”是用户与程序交互的用户界面, 所有的功能和应用逻辑都隐藏在界面背后;当用户对界面进行操作时, 所有的操作都通过界面以“Message/消息”的形式传递给应用程序的逻辑处理部分, 当然, 应用逻辑部分处理完毕后, 会把结果反馈给用户界面。
所以, 一个典型的窗口程序应该包括:用户界面部分和应用逻辑处理部分。反映在上面的对话框程序中, IDD_DIALOG1就是指定的对话框资源的标示, 就是“用户界面部分”;函数MainDlgProc () 就是“应用逻辑处理部分”, 负责对收到的用户的操作进行信息加工, 并把加工后的信息反馈给“用户界面部分”。
窗口过程函数MainDlgProc () 的声明:INT_PTR CALL-BACK MainDlgProc (HWND, UINT, WPARAM, LPARAM) , 函数的定义如下:
WM_COMMAND是Windows消息中很重要的一种消息, 用户操作对话框上的控件, 就会触发WM_COMMAND消息, 参数wParam的低位的两个字节 (用宏LOWORD (w Param) 可以取出来) 标示了发送消息控件的ID, 据此判断, 就可以知道是哪个控件发送的消息;而wParam的高位的两个字节 (用HIWORD (wParam) 取出) 区分了进一步的消息类型。
3.1 监控剪贴板
需要向MainDlgProc () 函数框架中加入应用逻辑———对系统的剪贴板进行监控, 一旦剪贴板有变化, 则获取其内容并分析, 如果剪贴板内容是有效的下载链接, 则将其显示在“下载链接”编辑框;然后从“下载链接”中的提取文件名, 显示在“文件名称”编辑框中。
对于系统剪贴板, 所有应用程序都可以对其监控, 凡是监控剪贴板的窗口都应该加入到一个Clipboard Viewer Chain/剪贴板查看者链中, 当然, 如不需要监控剪贴板时, 窗口需要把自己从Clipboard Viewer Chain中移除, 而且Clipboard Viewer Chain中的所有窗口都应该处理WM_CHANGECBCHAIN和WM_DRAWCLIPBOARD消息, 以向Clipboard Viewer Chain中的后续的窗口传递消息。
Windows剪贴板操作方法:
(1) 首先把某个窗口加入到Clipboard Viewer Chain, 调用SetClipboardViewer () 函数。
(2) 在该窗口中必须处理两个消息:WM_CHANGECBCH AIN消息和WM_DRAWCLIPBOARD消息。当有窗口从Clipboard Viewer Chain中移除时, 产生WM_CHANGECBCHAIN消息, 应用程序需要维护Clipboard Viewer Chain;当剪贴板内容发生变化时, 会产生WM_DRAWCLIPBOARD消息, 利用这个消息Clipboard Viewer窗口可以获取并处理剪贴板的内容, 同时将其发送给Clipboard Viewer Chain中的下一个窗口。
(3) 当退出窗口时, 解除该窗口和Clipboard Viewer的关系———即从Clipboard Viewer Chain中删除本窗口:
3.2 选择保存目录
当用户点击“浏览”按钮时, 弹出“浏览文件夹”对话框, 可为待下载的文件选择保存位置。这涉及到Windows Shell编程的部分知识, 调用函数SHBrowseForFolder () 函数可以弹出“浏览文件夹”对话框———用户可以在其中选择合适的保存路径。在WM_COMMAND消息处理中加入以下代码:
点击“浏览”按钮时, 会弹出“浏览文件夹”对话框, 如果不指定初始目录, 则默认是“我的文档”;如果要指定初始目录, 则方法如下:
(1) 设置回调函数:bi.lpfn=BrowseCallbackProc;如上面代码粗体部分所示。
(2) 声明并定义回调函数, 函数声明:int CALLBACKBrowseCallbackProc (HWND hwnd, UINT msg, LPARAM lp, LPARAM pData) , 函数定义如下:
3.3 文件下载模块
当用户点击“下载”按钮, 则启动下载线程, 需要添加代码到WM_COMMAND消息处理部分:
CreateThread (NULL, 0, TDownload, NULL, 0, &ThreadId) ;成功执行, 则会启动一个新线程, 并在该线程中和HTTP服务器建立TCP连接;向HTTP服务器发送“HTTP请求消息”;接收来自HTTP服务器的“HTTP响应消息”;从“HTTP响应消息”中提取出待下载文件的信息, 并保存到文件。
线程函数的声明:DWORD WINAPI TDownload (PVOID p Param) , 函数定义如下:
3.4 显示下载状态
下载线程应该下载期间的工作状态和下载进度通知给主窗口, 所以下载线程需要和主窗口之间通信,
利用Windows消息机制, 在下载线程中, 根据下载线程的执行状态向主线程发送自定义的Windows消息, 可利用SendMessage () 函数, 比如:SendMessage (g_hDlg, WM_STA-TUS, wParam, 0) , 表示向主窗口g_hDlg发送WM_STATUS的自定义消息, wParam参数值自定义为状态代码, 如下:
消息值WM_STATUS是我们自定义的, 因为Windows开放给用户的消息值是WM_USER开始的, 即自定义的消息值>=WM_USER就可以。
同时, 需要在主窗口的消息处理器中添加对消息WM_STATUS的处理例程, 如下所示:
3.5 显示下载进度
下载过程中, 主窗口上的进度条控件会显示下载进度———由文件下载线程把已下载文件的大小, 利用Windows消息, 传递给主窗口线程, 经计算后, 在进度条中显示, 同时也显示百分比。
进度条的初始化———当接收到“下载线程”关于待下载文件大小时, 就设定进度条的范围 (最小值和最大值)
当收到“下载线程”的消息时, 就步进进度条, 在主窗口的窗口函数中, 添加如下代码:
3.6 终止下载线程
当用户点击“终止下载”按钮时, 就关闭TCP连接, 终止下载线程, 在主窗口的窗口函数的WM_COMMAND消息处理中添加代码:
3.7 打开文件所在的文件夹
当用户点击“打开所在文件夹”按钮时, 启动资源管理器, 并显示当前下载文件所在的文件夹, 方便用户处理下载文件。在主窗口的窗口函数WM_COMMAND消息处理中, 添加如下代码:
3.8 涉及到的自定义函数和结构体
(1) GetIP () , 用以把指定域名解析成IP地址。
(2) GetFileLen () , 通过分析URL, 用以获取待下载文件长度。
(3) GetMsgBodyPos () , 通过分析HTTP响应消息, 用以获取消息体在响应消息中的位置函数。
(4) IsHttp () , 通过分析URL, 判断该URL的协议类型是否为HTTP。
(5) AnalyzeURL () , 通过分析URL, 从中分离出协议类型、主机名、端口号、相对路径和、文件名。
其中, 用以获取IP地址的函数:
用以获取待下载文件长度的函数:
用以获取消息体在响应消息中的位置函数:
函数IsHttp () , 判断指定的URL, 其协议类型是否是HTTP, 如果是则返回1, 否则返回0。
函数AnalyzeURL () , 从URL中分离出协议类型、主机名/IP地址、端口号、相对路径、文件名。
结构体_SAVEINFO记录了待下载文件的相关参数———URL、目标主机名、端口、相对路径和文件名、本地保存目录、本地文件名。
3.9 运行和调试环境
以上程序是在Windows XP SP3平台上, Visual Studio 2005VC++环境下, 调试通过, 因为Winsock 2不支持Unicode, 所以在“属性管理器”中把项目的“字符集”修改为“多字节字符集”。
4 结语
下载引擎的设计与实现 篇5
本文设计不仅实现了文件的上传和下载,还针对一些较大文件的上传提出了一种分块上传的思想。先指定用户想要的文件块的大小,这个值决定了文件要被分割的块数,较大的文件分割成若干块,每块都以一条记录的形式写到数据库中。当某条记录写数据库失败时,只需将那些写数据库失败的文件块重新上传,不需要将整个文件重新上传。采用这种方式可以提高文件上传的效率,节约重新上传时写数据库的时间。但下载时,如果用户需要完整的原始文件,原来属于同一个文件的分块则需要重新写到一个文件中。本文使用边下载、边合并的方法,实现了分块文件的合并下载。用户可以根据自己的需要,针对性地下载其中的部分文件块。读取一个文件分块相比读一个完整的大文件要快很多,文件的分块与合并提高了文件的上传下载效率。值得注意的是,在设置文件分块时,分块的大小要适度,否则会影响软件的运行效率[3],用户可以根据实际要求设置文件分块的大小。
1 大文件分块上传和下载软件的实现
1.1 文件的分块
将一个较大的文件上传到数据库时,上传速度往往会受到网络宽带的影响。针对较大文件的保存与管理,需对其进行分块,可以根据网络的带宽设置文件块的大小,假设每个文件上传的时间不超过5 s,设带宽为k Mb/s文件块的大小Block Size可以设置的范围最好能够满足式(1):
若文件块的大小用Block Size表示,则文件分成的块数n Count与文件的大小之间的关系为:
其中Flength代表原始文件的大小,K代表最后一个文件分块的大小。因为文件的大小与文件块的大小不一定刚好是整除的关系。最特殊的情况就是某文件的大小刚好小于文件块的大小,此时的文件就只有一块,即该文件本身。
1.2 分块文件的上传
将分块文件上传到数据库之前,首先要在数据库中创建一个存储文件信息表,并定义相关的字段,方便用户查询和管理[4]。数据库表中主要的相关字段包括:文件编号、文件名、文件大小、基本路径、相对路径、文件块大小、文件块编号、文件类型、文件内容等。
文件上传到数据库主要步骤为:(1)将文件的名称、路径、大小、类型等基本信息写入数据库;(2)根据这些基本信息查找对应的记录,并将文件的内容写到blob字段中,文件内容以二进制的形式存贮在数据库中[5,6]。
文件分块上传时,首先连接服务器端的数据库,在数据库连接成功的条件下,遍历要上传的文件所在的路径。当查找到要上传的文件时,根据文件分块的大小,计算文件分割的块数和最后一个文件块的大小,从第一个文件块开始,计算过程如下:
(1)判断是否成功连接到数据库。
(2)判断这是否为最后一个文件块,如果是,则从文件中读取最后一个文件块,写入数据库后结束;否则从文件中读取Block Size个字节。
(3)用Insert命令在对应的表中写入文件的编号、文件名称、文件大小、文件的基本路径及相对路径、文件类型、文件块的大小和编号。
(4)通过文件编号、文件路径,文件名称和文件块编号查找相应的记录。
(5)将要写入数据库的文件内容保存在一个安全数组中,并调用Append Chunk()函数将该块文件内容填到对应的blob字段当中,并更新记录。
(6)为写入记录中的文件的路径、文件名以及文件块编号设置标记,方便重新上传时定位断点的位置,跳转到步骤(1)。
文件分块上传的流程图如图1所示。
如果服务器数据库与客户端的连接断开,将导致文件上传失败。在客户端与服务器端数据库重新建立连接后,需要续传文件,同时要通过断开数据库时的标记,找到上次上传文件的断点。
续传文件时,为了找到文件续传的起始位置,依然要遍历文件所在的路径,通过文件路径和名称找到对应的文件,再使用文件块的编号和文件块的大小获取下一次文件要上传的位置。设offset为文件指针的偏移值,Block No为文件块的编号,Block Size为文件块的大小,三者之间的关系如下:
式中,被标记文件块的编号Block No乘以文件块的大小Block Size,就是续传时读取文件的偏移值。通过这个方法,就可以找到断点所在的文件块位置,实现文件的续传,从而避免重新上传之前已经写入数据库的文件块。
1.3 分块文件的下载
因为文件是保存在数据库中的,用户可用通过SQL命令对数据库中的记录进行增删查改等操作,这比存储在FTP服务器中的文件处理要方便很多。下载的过程其实就是上传的逆过程,思想相似。
下载时根据相关的查询条件,如果存在符合条件的记录,即可对这些记录保存的文件进行下载,在成功连接到数据库的条件下,从第一条记录开始执行以下过程:
(1)判断是否成功连接到数据库。
(2)判断该记录是否超过最后一条记录编号,如果是,下载结束;否则跳转到步骤(3)。
(3)从记录中获取文件的类型、文件名以及相对路径,判断该文件是否已经存在,如果不存在,则根据文件的类型创建一个文件,以可追加的形式打开文件。
(4)调用Get Chunk()函数获取blob字段中的内容,并保存在一个安全数组中,最后将安全数组中的数据写入文件。
(5)关闭文件,并标记该记录中的文件路径、文件名以及文件块编号,并跳转到步骤(1)。
1.4 分块文件的合并
本文虽然实现了文件的分块下载,但是在实际情况中,人们通常希望使用完整的文件,而不是一个文件块,所以在下载的过程中需要将各个文件的分块重新合并成一个文件。本文采用的方法是在下载的过程中即可进行合并操作,文件合并下载的流程图如图2所示。
文件的合并是文件合并下载过程中的一部分,即每次下载某条记录中的文件内容时,先判断该文件块将写入的文件。
用户根据文件名称,文件路径等信息查找所需要的文件,如果存在符合条件的记录,就依次访问这些记录,并将每条记录中的文件内容读取出来,写入相应的文件中。从查询到的第一条记录开始:
(1)判断是否已经访问了最后一条符合条件的记录,如果是,则结束,否则转到步骤(2)。
(2)获取文件的路径、文件名称、文件类型等基本信息,判断当前路径下是否已经存在这样的文件,如果不存在,将创建一个对应的文件;否则跳转到步骤(3)。
(3)将记录中的文件相对路径、文件名两个字段的内容与上一条记录中的相对路径和文件名匹配,如果相同,则将文件内容追加到该文件;否则根据该文件块的基本信息重新创建一个文件。
(4)标记该条记录并移到下一条记录,并跳转到步骤(1)。
所有记录被访问完的同时,所有的文件分块都被写入了相应文件中,既不会出现文件内容的覆盖问题,也不会额外地占用存储空间。
2 实验分析
通过测试发现,文件的完整上传所消耗的时间最短,但是上传失败后要重新上传整个文件。如果使用文件的分块上传,文件分块的大小要适当,分块越多,上传的速度就越慢。因为记录每个分块文件的基本信息也要消耗一定的时间,在上传失败需要重新上传的情况下,只需上传剩下的没有上传成功的文件,效率有所提高。在下载的过程中,单块文件明显比整个文件的下载要快,因为单块文件下载只需要读取块数据。而文件的合并下载时间比整块文件下载时间要长,因为在合并的过程中要判断各个文件块是否来源于同一个原始文件,会消耗一定的时间。
相对于普通的将文件上传到FTP服务器,本文实现了基于Oracle数据库的大文件分块上传下载应用软件,将文件的内容以二进制的形式分散保存在Oracle数据库中,这不仅可以对大量数据信息进行管理,还可以使得不同的用户共享很多数据信息。文件的分块上传采用文件分割技术,将文件分块保存在数据库中。通过文件的续传,避免了由于各种网络原因导致的写数据库操作失败,需要将整个文件重新上传的问题。文件的合并下载解决了同一个文件中不同分块的合并问题,避免了先下载文件再进行合并的做法,提高了软件的运行效率。
摘要：针对大文件在网络存储过程中可能存在的上传和下载失败问题,提出了一种利用数据库进行分块存储和管理较大文件的方法。将一个较大的文件分割成多块,分别对分割后的每一块进行上传或下载,从而避免了网络因素对直接上传和下载较大文件所产生的影响。测试表明,通过所提出的分块与合并方法,可以有效地避免文件上传和下载过程中可能出现的失败问题,提高了上传和下载的效率。
关键词：文件存储,oracle数据库,文件上传,文件下载,文件分块,分块合并
参考文献
[1]冯素梅.基于FTP的文件上传与下载研究[J].北京电力高等专科学校学报(自然科学版),2010,27(5):197-199.
[2]陶宏才.数据库原理及设计[M].北京:清华大学出版社,2007.
[3]张翼.BLOB数据优化算法及其应用[J].计算机测量与控制,2011(6):1478-1480.
[4]徐孝凯,贺桂英.数据库基础与SQL Server应用开发[M].北京:清华大学出版社,2008.
[5]谢华成,张昆朋,范黎林,等.基于文件分割的二进制大对象存取算法[J].计算机应用,2011,31(10):2612-2616.
下载引擎的设计与实现 篇6
AVR单片机是由ATMEL公司研发的增强型内置Flash的RISC(Reduced Instruction Set CPU)精简指令集高速8位单片机,目前广泛应用于工业控制、通讯设备、家用电器和仪器仪表等各领域。很多AVR单片机都提供了引导加载功能,即bootloader功能,单片机可以通过运行常驻 在Flash中一个特 定区域的bootloader程序,实现“在应用编程”(IAP)以及系统程序的自动更新等。单片机的固件就是指单片机的系统程序,是存储在Flash中实现系统功能的根本组件,在开发阶段,其也就是开发者为控制单片机所编写的功能程序。
AVR单片机的bootloader功能同其他一些单片机不同,它的bootloader程序没有固化在芯片内部,出厂时是空的,需要由用户(开发者)设计实现,这样就增加了bootloader的灵活性和适应性,但也增加了开发者使用bootloader功能的难度,特别是对初学者。如果bootloader程序在单片机出厂时固化在芯片内部, 厂家一般会 提供相应 的固件下 载的上位 机软件,而AVR单片机的bootloader程序是开发者自己编制的, 也就没有统一 的上位机 软件。 针对此问 题,本文以ATMega128单片机为例,利用AVR单片机的IAP功能,设计了一套固件下载与更新系统,便于AVR单片机的开发与使用。
1AVR单片机IAP功能的实现原理
AVR单片机的IAP功能是允 许在单片 机的Flash高端地址处常驻一个引导加载程序,引导加载程序可以对整个Flash存储器进行读写,还可以对自身进行更新修改,甚至删除。引导加载程序区的大小和地址可以由芯片的熔丝位进行设置,并可以锁定或加密。
有了bootloader功能程序,可以在单片机脱离编程器的状态下让单片机更新自己的程序,该功能称为产品的固件升级。bootloader程序可以使用任何可用的数据接口,根据相关协议,读取单片机固件程序代码 (二进制代码),然后将代码写入到Flash存储器指定的区域,完成系统程序(固件)的更新。
2固件下载与更新系统的工作原理
固件下载与更新系统包括上位机(PC机)程序、单片机bootloader程序和上位机与单片机通信接口3部分。在本系统中,上位机与单片机的通信接口采用三线制串口,数据传输协议采用应用广泛的Xmodem协议。图1为固件下载与更新系统的工作流程,具体如下:
(1)上位机软件将要升级或下载的单片机固件文件准备好。
(2)连接上位机与单片机的串口通信。
(3)上位机向串口连续发送请求 下载的命 令字符,等待单片机回应。
(4)单片机上电复位,收到上位机请求下载命令字符后回应相应的命令字符。
(5)上位机收到可以下载命令字符后,根据相应的协议对固件文件数据打包,形成数据帧,并发送。
(6)单片机把接收到的数据帧进行拆包,并校验, 校验正确后存到Flash存储器指定的区域,如果校验失败,则回送重发命令字符。
(7)数据传送完成,单片机回应相应命令字符后转入运行固件程序,更新或下载结束。
3固件下载与更新系统的具体实现
3.1AVR单片机bootloader程序的设计
AVR单片机的bootloader程序与上位机的通信协议采用Xmodem协议。Xmodem协议是一种使用拨号调制解调器的个人计算机通信中广泛使用的异步文件传输协议,Xmodem协议以128个字节块的形式传输数据,并且每个块都使用一个校验过程来进行错误检测,如果接收方关于一个块的校验和与它在发送方的校验和相同时,接收方向发送方发送一个认可字节,如果校验和不同,则返回一个<nak>字符(negative acknowledgement character),要求发送方重新发送上一个数据块。校验方式采用16位CRC校验。
图2为bootloader程序流程图,具体如下:
(1)单片机上电复位,bootloader程序开始运行。 通过设置单片机的熔丝位,确定单片机是从bootloader程序开始运行,还是从0x0000地址开始运行。
(2)初始化串口,等待接收串口数据,在3s内如果接收到下载程序的请求指令,给上位机应答,准备接收数据,如果没有收到下载程序的指令,则退出bootloader程序,从Flash的0x0000开始运行应用程序。
(3)如果收到下载指令,开始接收数据帧,并对数据帧拆包,进行校验,如果有错,回复重发指令,如果正确,把数据块写入到Flash相应的页面,直到全部数据接收完,通知上位机全部接收完成。
(4)单片机将中断向量表迁移到 应用程序 区头部,跳转到Flash的0x0000位处,开始执行应用程序。
bootloader程序可以用C语言编写,也可以用汇编语言编写,还可以在C语言中嵌入汇编语句,用来完成特殊功能。如果用C语言编写,AVR-libc库提供了对bootloader功能的支持,包括擦除Flash页、填充Flash页、将数据写入页临时缓冲区等函数。
bootloader程序可以在ICCAVR中编译,在编译时进行如下设置:在菜单Project->Options的Compiler Options设置选项 窗口,在Device Configration栏中选定器件 为Atmega128(本文以Atmega128为例),Program Type选定为Bootloader,bootsize选择为1kwords。
下载bootlaoder程序时还要对Atmega128的熔丝位进行如下配置:
(1)配置M103C熔丝位,使芯片工 作在Atmega128方式 (Atmega128可以工作 在兼容M103C模式)。
(2)配置BOOTSZ1和BOOTSZ0熔丝位,设定Bootloader区的大小 为1 024个字,起始首地 址为0xFC00。
(3)配置BOOTRST熔丝位,设定单片机上电启动或复位时从bootloader区的起始地址处开始运行, 即每次Reset复位后,从0xFC00处执行bootloader程序,默认是从0x0000处开始。
下载bootloader需要编程下载器下载,下载完后, 还可以配置LB2、LB1、BLB12和BLB11熔丝位,对bootloader区进行加密和安全锁定。
3.2上位机下载程序的设计
上位机下载程序主要完成以下几个功能:
(1)打开与单片机连接的串口并初始化,向串口发送下载程序的指令字符,等待回应。
(2)单片机回应后,将应用程序(固件)文件进行转换(用编译软件编译后的应用程序一般为HEX格式,传给单片机的需要bin格式),转换完成后,将数据打包形成数据帧。
(3)将数据帧通过串口传送给单片机,并对单片机的反馈进行响应。
(4)当文件全部正确传送后,关闭串口,用户程序下载成功。
在等待单片机回送命令时,等待时间是一个不确定的时间,所以在程序中设置单独一个线程,用于和单片机交互传输数据,主线程响应程序主界面上的用户输入。
4AVR单片机固件下载与更新系统的硬件设计
单片机的硬件比较简 单,因为AVR单片机Atmega128提供了两个串口,利用MX232芯片把单 片机串口的TTL电平转换为RS232电平。AVR单片机串口接线图如图3所示。
5结语
中文智能搜索引擎的设计与实现 篇7
计算机技术和互联网技术迅速发展, 造成的互联网络泡沫迅速膨胀, 给搜索结果精确程度带来了巨大的挑战。想要把如此庞大而又复杂的网络环境中对自己有用的信息提炼出来, 必须使用搜索引擎来完成。想要很方便的构建一个根据自己的需要而专门定制的搜索引擎, 可以通过本设计所使用的Lucene.net。本文阐述了较为简单的中文智能搜索引擎的开发过程的关键问题, 对目前的搜索以及编程方面的新技术进行了研究。
1 开发环境
中午智能搜索引擎采用微软提供的.NET是一种面向Web服务的开发平台, 由.NET企业服务器、框架、Web服务等几部分组成, 可以提供较为全面的解决方案。因此在本系统的开发中, 采用ASP.NET作为本设计的开发工具。我们选择了微软公司的.NET作为开发平台。同时, 选择C#作为开发语言, 使用Microsoft Visual Studio.NET 2005作为开发平台;使用Microsoft SQL Server 2005作为后台数据库。使用Ajax程序对搜索引擎系统进行优化, 可以实现浏览器页面的局部刷新功能。Lucene作为一个高性能的信息检索工具库, 能够为搜索引擎应用提供一个工具包, 同时配合Lunene.net完成, 它可以嵌入到程序中为程序提供关键词搜索功能, 也可以用来对文档建立索引。
2 Lucene.net构建搜索引擎原理
搜索引擎的工作过程分为3个步骤:一是抓取网页, 二是建立索引数据库, 三是搜索索引数据库。在全文搜索中, 在程序之中预先定义一个或者一定地址范围内网站, 由程序中的Spider程序模块从这个预先定义的网站开始采集网页资料, 并且沿着这个 (或这些) 网站上的链接进行跳转, 并循环该过程。Spider采集的网页, 首先要进行程序分析过程, 根据预先给定的算法运算后, 其结果添加到索引数据库中。而用户日常平时进行的全文搜索引擎, 呈现给用户的仅是一个检索的界面。其工作过程是, 首先根据用户检索的内容提相符的所有的相关网页, 最后按照预先设定的规则, 将得到的网页列表结果显示出来。由于存在各种各样的搜索引擎, 它们预先设定的规则以及索引数据库不尽相同, 因此用户看到的最后搜索结果也因而不同。
根据预先设定的初始网页, Spider程序可以自动的访问网络, 对这个页面进行访问, 并且能够提取该网页上的所有URL。而且, Spider程序还能够依次跳转到URL所对应的其他页面, 继续提取这个二级页面上的URL, 最后不断的重复这个过程, 直到达到其程序限定的级数停止[1]。Spider程序爬出的所有网页都经过分析索引程序对其进行分析, 程序会提取网页页面的相关信息, 这些信息包括网页的网址, 网页内容的所使用的编码类型, 网页代码头中所包含的网站关键字等等一系列信息。然后根据提取的这些相关信息构造网页索引数据库, 并采用预先设定的排序算法对其进行排序, 因此当用户进行搜索时, 搜索程序会检测用户所输入的关键词, 然后根据这个关键词查找服务器后台的索引数据库, 将所有符合这个关键词的相关网页都提取入栈。最后, 页面生成系统将调用包含了查询到的网页的栈, 提取栈内网页的地址和含有高亮关键词部分的页面摘要内容整合成一个页面呈现给用户。由于每个搜索引擎的网页索引数据库不同, 而且搜索引擎只能搜到数据库里储存过的内容, 所以用户在不同的搜索引擎下进行搜索, 所得的结果也不会完全相同。
3 搜索引擎的设计与实现
3.1 搜索引擎模型
模型包括爬虫、索引生成、查询及系统配置部分。爬虫包括:网页抓取模块、网页减肥模块、爬虫维持模块。索引生成包括:基于文本文件的索引、基于数据库的索引。查询部分有Ajax、后台处理、前台界面模块如图1所示。
3.2 数据库设计
本课题包含一张用于存放抓取回来的网页信息如表1所示。
3.3 模块设计与实现
该模型按照功能划分了3个部分, 一是爬虫抓取网页部分, 二是从数据库建立索引部分, 三是从前台页面查询部分。从一个或几个初始网页开始, 获得初始网页上的URL, 并加入队列, 直到满足系统限定的诸如域名空间或者是网页抓取级数的的停止条件。实际应用中主要以绝对地址和相对地址来的形式来表现获取到的URL。一个准确的、无歧义的Internet资源的位置, 包含域名 (主机名) 、路径名和文件名叫做绝对地址[2]。但是相对地址只是绝对地址的一部分。得到的信息包括网页标题、内容、链接、抓取时间等, 然后将这些信息经过系统程序算法的筛选, 保存到数据库中。程序计算后去掉多余的HTML标签、Javascript等多余信息, 如果不经过处理就会使搜索变得不精确。
想要爬虫程序能继续运行下去, 就得抓取网页上的其它URL, 所以要用正则将这个网页上的所有URL提取出来放到一个队列里。通过多线程技术用同样的方法, 依照队列次序继续抓取网页。
Lucene提供了Document, Field, Index Writer, Analyzer, Directory五个基础类对文档进行索引。一个Document对象由多个Field对象组成。Document用来描述包括HTML页面、电子邮件或者是文本文件等类型的文档[3]。如果用数据库记录来理解每个Document对象, 那么每个Field对象就是记录对应的某个字段。Analyzer类是一个有多个实现的抽象类。在索引文档之前, 需要先由Analyzer进行分词处理。可以针对不同的语言和应用选择适合的Analyzer。Analyzer把分词后的内容交给Index Writer建立索引。
方便用户查询是所有搜索引擎的目标。在查询页面输入用Lucene的搜索引擎中, 需用到Lucene提供的方法, 可从所建立的索引文档中得到结果。
在配置网页爬虫程序时, 预先将一个一个有效的URL输入在控制面板里, 然后由这个URL开始依照级别遍历相关的链接, 然后在网页数据库里经这些连接存贮下来, 然后就由索引生成程序读取, 对每条记录生成索引记录, 存放于生成的索引库文件里。生成索引需要调用Lucene.Net类[4]。索引生成后可以直接在查询页面上输入关键字, 对系统生成的索引库的查询, 并反馈信息, 还可以精确定位到信息的出处。
4 结语
在这个网络泡沫迅速膨胀时代, 网络中有成千上亿个网页, 仅仅通过人工方式对网页进行收集和整理的工作量的巨大难以想象的。所以通过智能搜索来收集网络上的网页资料, 由系统建立索引数据库来代替庞大的、不可能完成的人工操作。用户在浏览网页需要搜索相关内容的时候, 就会通过选择关键词进行搜索, 智能搜索引擎就需要为用户显示包含该关键词的所有网页呈现给用户, 程序需要根据索引数据库中所存储词条与关键词的相关度进行排序。这个过程需要一系列的复杂的算法进行大量计算, 从而将用户需要的信息显示在反馈的网页上面, 这样用户就能快速的得到检索结果。
摘要：大数据时代网上信息量快速增长, 智能搜索系统可以帮助用户快速定位查询的资源。文章主要探讨了搜索引擎的原理, 阐述了使用Lucene与Ajax实现智能搜索的方法。对Lucene的搜索引擎模型、数据库设计、模块设计进行了详细分析, 对Lucene.net构建搜索引擎原理的关键问题进行了研究。
关键词：Lucene,异步更新,Ajax,搜索引擎
参考文献
[1]刘东君, 李德泉, 周勇, 等.基于Lucene的非结构化文档全文检索系统研究与实现[J].软件导刊, 2013 (10) .
[2]艾丽娟.智能搜索引擎发展现状及关键技术[J].电子技术与软件工程, 2013 (10) .
[3]兰蔚巍, 李海生.浅谈智能搜索引擎技术及其发展趋势[J].科技信息, 2010 (28) .
工作流引擎过程定义的设计与实现 篇8
关键词：工作流引擎,过程定义,解析,版本控制
1 工作流引擎的过程定义
过程定义是一个业务过程支持自动化操作的形式化表现, 过程定义由任务网络及其关系, 过程开始和终止的条件, 任务资源, 诸如参与者、相关的IT应用及数据等组成。在工作流引擎的过程定义方面, 工作流管理联盟定义了工作流模型的一个元模型, 这个元模型有利于建立可以在多个工作流产品之间交换信息的模型。由该模型可知, 工作流定义反映了企业中的一个经营过程的目的, 它由多个活动与多个工作流相关数据组成, 其中活动是它的组成核心。活动对应于企业经营过程中的任务, 主要反映了完成企业经营过程需要执行哪些功能操作。活动所产生的任务项根据活动的类型执行, 如果活动类型为手动, 任务项就分配给活动的操作人员或组织单位的角色;如果活动类型为自动, 引擎就自动激活相应的应用程序完成任务。转换条件和相关数据主要负责为过程实例的推进提供导航依据。
2 过程定义语言的采用
本设计的过程定义语言采用的是XPDL (XML Process Definition Language) 。XPDL是基于过程定义元模型, 是由工作流管理联盟制定的一种采用符合XML语法的文本描述语言。XPDL根据过程定义元模型, 制定了自己的语言结构, 用一个XML Schema表示, 通过该语言结构实现过程定义之间的相互转换。其中解决方案使用的是XML Schema中定义的主要元素“Package”和“Workfl ow Process”, 其元素结构如图1、图2所示。
3 过程定义文件设计
本设计方案选用了一个典型的经营过程:自行车的订购。根据流程图, 用XPDL表示该经营过程的文件主要内容如下所示:
4 过程定义的解析
XML开发组织为开发人员使用XML文档提供了许多API。通过这些API可以进行过程定义的解析, 最流行和广泛使用的API中的四种:文档对象模型 (Document Object Model (DOM) ) 、用于XML的简单API (Simple API for XML (SAX) ) 、DOM4J和用于XML解析的Java API (Java API for XML Parsing (JAXP) ) [3]。根据解析的机理大致可分成两种。第一种解析机理:解析器一次性读取完整文档, 接着在内存中构造一个树结构, 然后代码就可使用相关接口对这个树结构进行操作。采用这种工作方式的有DOM、DOM4J、JAXP。第二种机理:解析器基于事件, 实际上是通过串行的方式来处理文档的, 当解析器发现元素、文本和文档等元素开始或结束时, 它向应用程序发送消息, 由应用程序决定如何进行处理, 解析器本身不创建任何的对象, 采用这种工作方式的有SAX。这两种方式各有优缺点:第一种方式由于创建了内存树, 所以对内存树的操作就比较简单, 功能也强大, 程序可以通过各种办法对树进行遍历, 查找需要的元素。这种方式的缺点是:a、由于需要在内存中构建完整文档的树结构, 当文档很大时对内存就提出了比较高的要求。b、内存树会表示文档中每个元素, 但是如果程序只需要文档的一小部分, 那么那些根本就不会被使用对象的创建是很浪费的。c、解析器在程序运行前先要读取完整文档, 那么当文档很大时, 会引起程序运行的显著延迟。第二种方式由于基于事件响应, 解析器一旦发现对象要素开始时就会产生一个事件, 程序就会立即生成结果, 而不必文档解析完毕后才开始。特别是, 当程序只查找某些文档信息时, 程序只要一找到所要的内容就会抛出一个异常。该异常会使SAX解析器停止, 然后程序就可以用查到的信息开始做任何事了。当然也存在一定的缺点:a、SAX事件没处理文档各元素之间的关系, 须自己编写程序才能处理元素的关系。b、SAX事件是暂时的, 如果需要对XML中的数据进行多次访问, 那么就需要对该文档进行多次解析。综合上述因素, 同时考虑本设计方案的过程定义文档自身特点:文档规模相对都不是很大, 过程定义解析后, 对各个元素的操作要求高, 必须知道每个元素之间的关系, 所以决定采用针对编程人员操作比较方便的DOM4J和JAXP相结合的方式, 对过程定义解析提供接口。
在具有的实现过程中, 设计方案对过程定义中包含在XPDL_Schema规范中的元素通过DOM4J进行解析, 采用名称空间识别的办法 (父元素和子元素必须在同一名称空间中, 才可以通过父元素查找相应的子元素) , 完成对内存树的操作, 而针对定义在‘工作流过程’元素的扩展属性内的‘事务’元素, 方案采用JAXP进行解析, 直接通过元素的标记进行判断, 不考虑名称空间。通过两个接口的结合调用, 实现定义的工作流过程解析工作。
本方案的过程定义解析实现的部分代码如下:
(1) 用DOM4J接口完成过程定义中主要元素的解析:
5 流程版本的解决方案
5.1 实现的功能
(1) 运行过程中对过程定义的改变, 确保原流程继续正常运行。
(2) 流程管理员指定过程定义的版本, 引擎根据版本号, 调用、解析相应的过程定义, 实现流程实例的运行。
5.2 实现的思路
(1) 过程定义的改变, 使得过程定义文件中的元素的属性或其子元素的个数改变, 不同版本过程定义的保存形式一般有两种情况:a、修改原来的过程定义文件。b、另外生成一个xpdl过程定义文件保存改变后的过程定义。对于第一种情况, 经营流程的改变可以在过程定义的Workfl ow Processes的元素中添加不同的子元素“Workfl ow Process”, 根据“Workfl ow Process”中属性‘Id’和‘Name’定义不同版本的流程。采用这种方式保存, 在过程定义加载时就有两种方法, 一种是每次都加载所有版本的过程定义, 这种情况下, 如果有的版本的流程很少使用, 就会占用不必要的内存;另一种情况是通过版本的判断进行指定加载, 这种情况下, 如果一个经营流程下面本来就有多个“Workfl ow Process”, 这样在就会给版本判断带来困难。对于第二种情况, 由于不同版本的过程定义保存在不同的文件中, 在进行过程定义加载时, 就可以通过过程定义的文件名字来快速加载不同版本地过程定义, 从而避免了第一种保存方式的弊端。通过以上比较, 本设计方案采用第二种方法来保存不同版本的流程。
(2) 关于部分执行的过程实例, 如果流程版本更改, 其继续运行时采用哪种版本, 设计的想法是如果创建新的流程的时候, 使用更改后新的版本, 以前没有执行完成的过程实例还是按照原来的版本执行。根据这种思路, 主要需要解决的问题就是:如果流程没有中断, 即package包没有重新载入, package中的内容是不会改变的, 这样原流程可以继续进行, 关键是如果原流程挂起, 引擎重新启动, 两个流程采用的package包就不是同一个, 如何判断应采用哪个就是关键。其解决思路:a、把每个流程实例的package Id作为不同版本的xpdl过程定义文件唯一标志。b、在引擎启动后, 将每个流程实例的package Id保存到数据库中, 并且把流程的最新版本的package Id作为引擎启动后默认加载包的Id。c、引擎启动后, 首先加载默认的Package, 然后到数据库中查找没有完成的流程实例, 如果其package Id的值不是默认的package Id值, 加载其相应的Package, 这样原流程恢复后就可以根据package Id采用原来的package包。d、新的流程也可以采用人工指定的方式加载指定的package包。
5.3 开发约定、应用接口
(1) xpdl过程文件的命名规则, 每个过程文件名字为其过程定义中“Package Id”的值, 扩展名称为xml, 例如Package Id="dreambike_300", 其相应的过程文件名称为:“dreambike_300.xml”;其中‘300’为版本号, 版本号用3位数字表示, 针对与同一个流程, 新的版本号必须比旧的版本号大。
(2) 过程文件的加载。第一部分是com.rongji.workflow.demo.dreambike.Bike Order Manager中相应函数的解释:a、public String get Lastestxml (String files[]) :得到最新版本的xpdl过程文件的名称。b、private void add Lastest Packge () :加载最新版本的xpdl过程文件。c、private void add Packgeby Id (String pkg Id) :加载指定版本的xpdl过程文件。第二部分是com.rongji.workfl ow.engine.Wf Engine中相应函数的解释:a、public Array List get Package Id And Proc Id () :得到数据库中没有完成的过程实例的Package Id和Process Id, b、public void recorve r Former Process Instanse (String package Id, String proc Id) :恢复指定package Id和process Id的过程实例。c、public void add Repository Manager (Wf Repository Manager ar, String process Name) :加载流程的应用到应用仓库中, 同时加载多个过程定义时, 应用仓库中针对不同的应用只保存一份。
参考文献
[1]河江斌.工作流管理系统研究及其在土地登记中的应用[D].河海大学, 2004, 11:19.
【下载引擎的设计与实现】推荐阅读：
搜索引擎实现05-23
《搜索引擎》教学设计09-25
搜索引擎研究与开发10-03
掌声教学设计下载09-22
新课程的引擎08-02
免费下载设计合同范本08-29
搜索引擎的使用07-29
未来的搜索引擎10-08
文秘专业毕业设计说明费下载10-16
搜索引擎的研究现状06-11