CN101447856A - 一种大容量文件传输方法 - Google Patents

Abstract

本发明提供一种大容量文件传输方法，该方法基于Xfer网络构架实现，该网络构架包括通过总线连接的主干网和多个板块网；每个所述板块网包括至少一个xPeer服务器和多个应用节点，所述主干网包括M－Peer服务器；所述大容量文件传输方法包括如下步骤：接收节点请求传输服务节点中的文件；接收节点所在板块网的xPeer服务器对携带所述请求的信令进行封装，然后与服务节点所在板块网的xPeer服务器进行通信，在M－Peer服务器的调度下，将所述文件通过总线传输至接收节点所在板块网的xPeer服务器上；3)接收节点从所在板块网的xPeer服务器获取所述文件。本发明的网络构架能够让大容量文件在企业内部各个板块之间直接进行快速、合理交换，降低劳动成本，提高节目生产效率。

Description

一种大容量文件传输方法

技术领域

本发明涉及计算机网络技术领域，具体地说，本发明特别涉及一种文件传输方法。

背景技术

目前，大多数企业的经营都涉及到多种性质不同的业务，因此在企业内部的计算机网络中，通常形成多个业务应用子网来分别满足这些业务的需求，而数据需要在各子网之间需要共享或者传输。以广电行业为例，当前国内外广电行业在信息化方面的总体发展方向是：网络化、信息化，根据在电视台的实际业务中涉及多种性质不同的业务需求，电视台内部形成多个业务应用子网来满足电视台“采、编、播、存、管”的整个电视工艺流程。其中，节目素材需要子网之间共享或者传输，因此，对文件传输方式需要一种合理可行的模式，而现有技术没有很好地解决这一问题。

首先，传统的文件传输方式一般是在两个子网不同应用系统之间点对点的通信和传输，一般这种情况下，两个系统都需要提供客户端和服务端程序，当需要进行文件传输的系统个数增加时，增加各个系统负担和运行成本。此种模式下，系统之间关联的数量是[N(N-1)]/2，每当增加一个应用系统时，系统的关联度增加N(参考图1和图2)，并需要在所关联系统上分别提供对新增系统的客户端和服务端程序。

再者，目前通用的文件传输协议不能很好的支持大容量文件传输。目前通用的文件传输技术包括文件拷贝、FTP文件传输协议、TCP/IP传输协议等。文件拷贝的方式，通常用于同一子网开放权限的两个传输终端之间的文件传输。而企业(如电视台)内部的业务板块网通常是各自组建，并且基于网络安全和数据安全的需要，具有较为严格的权限控制策略。因此，文件拷贝的方式，不适合用来打通电视台业务板块之间的数据互通，而且也不具有跨平台性。FTP(File Transfer Protocol)是Internet传统的服务之一，但是如果在系统内部架设FTP服务器，并不具有较好的扩展性，如果专门开发应用程序使用FTP协议进行文件传输在文件完整性校验上也不具备足够的灵活性。

最后，在文件传输过程中，有时会出现数据丢失(或损坏)的问题，为解决这一问题，需要对接收到的文件数据进行完整性验证。常见的数据完整性验证算法包括：MD5和SHA1。SHA1算法对路由器等网络组件的要求较高。而MD5是由RSA发明的一种消息摘要算法，具有快速和高效的优点。另外，使用JAVA语言开发的应用程序，可以方便的嵌入MD5算法。目前，Internet上很多国外的网站提供的下载资源都会同时提供一个md5验证文件。在接收端对整个文件进行一次md5编码，一旦验证失败，则将文件重新传输一遍。这种完整性校验方法能够有效地防止数据丢失(或损坏)，但当传输的文件数据量较大时，特别是传输媒体文件时，重新传输整个文件将耗费大量的资源，极大地影响传输速度，甚至还会造成网络拥塞，因此，迫切需要一种适合于大数据量文件传输的完整性验证方法。

发明内容

本发明的目的是克服现有技术的不足，解决跨网段数据传输、大数据量文件传输、文件数据的完整性保证和传输安全性等方面的技术问题，从而提供一种适合于大容量数据的文件传输方法。

为实现上述发明目的，本发明提供的大容量文件传输方法，该方法基于Xfer网络构架实现，该网络构架包括通过总线连接的主干网和多个板块网；每个所述板块网至少包括一个xPeer服务器和多个应用节点，所述主干网包括M-Peer服务器；所述大容量文件传输方法包括如下步骤：

1)一个应用节点(下文中将其称为接收节点)请求传输另一应用节点(下文中将其称为服务节点)中的文件；

2)所述接收节点所在板块网的xPeer服务器对携带所述请求的信令进行封装，然后与所述服务节点所在板块网的xPeer服务器进行通信，在所述主干网的M-Peer服务器的调度下，将所述文件通过总线传输至所述接收节点所在板块网的xPeer服务器上；

3)所述接收节点从所在板块网的xPeer服务器获取所述文件。

上述技术方案中，所述步骤2)中，各板块网的xPeer服务器采用SimpleFTP协议进行通信，所述SimpleFTP协议的程序包包括命令模块、文件查验模块、数据传输模块、完整性验证模块和错误重传模块。

上述技术方案中，基于SimpleFTP协议的文件传输过程如下：

21)在所述命令模块，发送获取文件信息消息，该消息中携带需要验证的远程文件的文件名；

22)在所述文件查验模块，返回服务应答消息，该应答消息中携带所述远程文件的数据量大小的信息；

23)在所述命令模块，根据文件的数据量大小，将文件分为多个数据段；

24)在所述命令模块，选取一个数据段，发送传送文件消息，该传送文件消息携带所述数据段传输的起始点和结束点；

25)在所述数据传输模块，根据收到的传送文件消息进行数据传输；

26)在所述完整性验证模块，在接收完本次传输的数据段后，对该数据段进行完整性验证；如通过完整性验证，则回到步骤4)继续传输下一个数据段，直到所述远程文件传输完毕；

27)在所述错误重传模块，当本次传输的数据段未能通过完整性验证时，客户端重新发送传送文件消息，请求重新传输该数据段。

上述技术方案中，所述步骤23)中，所述每个数据段的数据量为256k的整数倍。

上述技术方案中，所述每个数据段的数据量在1M至10M的范围内。

上述技术方案中，所述文件为媒体文件。

上述技术方案中，所述步骤27)中，为重新传输所述数据段设置一个最大次数，当一个数据段重传次数达到该最大次数时，则舍弃该数据段。

上述技术方案中，所述步骤26)中，所述完整性验证的方法可以采用MD5算法或CRC算法。

与现有技术相比，本发明能够达到如下技术效果：

本发明的网络构架能够让大容量文件(如媒体文件)在企业(如电视台)内部各个板块之间直接进行快速、合理交换，降低劳动成本，提高节目生产效率。另外，本发明能够通过简单的注册方式增加需要进行文件传输的系统个数，维护方便。本发明的快速文件传输协议可以方便的组织、管理和调度文件传输的过程。本发明的快速文件传输协议在传输的同时，还对数据进行摘要计算和验证，保证了数据传输的安全性。另外，本发明的快速文件传输协议能够更好地支持基于每个子文件块的完整性校验，因此能够以较小的代价进行损坏数据的再传输，降低了大数据量文件重新传输的带宽及资源占用率，在最大程度上降低网络环境的设备压力，又可以充分保证媒体文件的完整。本发明特别适合于应用于大容量的企业(如电视台)媒体文件传输。

附图说明

图1是传统的文件传输网络构架示意图；

图2是传统的文件传输网络构架进行扩展的示意图；

图3是本发明的网络构架示意图；

图4是M-Peer系统流程图；

图5是M-Peer调度流程图；

图6是本发明在各应用系统间进行文件传输的示意图；

图7是本发明在进行应用系统扩展的示意图；

图8是基于SimpleFTP协议进行文件传输的时序图；

图9是本发明在文件传输过程中进行完整性校验的流程图。

具体实施方式

本发明提供的大容量文件传输方法基于Xfer网络构架实现，该网络构架包括通过总线连接的主干网和多个板块网；每个所述板块网至少包括一个xPeer服务器和多个应用节点，所述主干网包括M-Peer服务器；所述大容量文件传输方法包括如下步骤：

1)一个应用节点(下文中将其称为接收节点)请求传输另一应用节点(下文中将其称为服务节点)中的文件；

2)所述接收节点所在板块网的xPeer服务器对携带所述请求的信令进行封装，然后与所述服务节点所在板块网的xPeer服务器进行通信，在所述主干网的M-Peer服务器的调度下，将所述文件通过总线传输至所述接收节点所在板块网的xPeer服务器上；

3)所述接收节点从所在板块网的xPeer服务器获取所述文件。

下面结合附图和具体实施方式对本发明作进一步详细描述：

实施例1

本实施例中提供了一种新的企业网络构架。

以电视台为例，对企业网络构架的各细节进行详细描述。本实施例中所传输的文件主要是指企业媒体文件。参考图3，本实施例的网络构架包括：通过企业媒体总线(Enterprise Media Bus，EMB)连接的主干网和多个板块网；每个所述板块网至少包括一个xPeer服务器(以下简称xPeer)，所述各板块网通过xPeer和总线在板块间进行文件传输；所述主干网包括M-Peer服务器(以下简称M-Peer)，所述M-Peer对各xPeer的传输任务进行调度。本实施例中将利用M-Peer和xPeer进行文件传输的体系称为Xfer。另外，所述主干网还包括消息流服务器(MFS)。

本实施例中，文件传输任务调度是由M-Peer完成的，M-Peer作为xPeer和传输任务调度的执行部分，除起到Xfer与MFS交互作用外，同时完成对多个xPeer之间和对多个传输任务之间的调度作用。

M-Peer的主要功能包括：

当MFS发起一个任务时，M-Peer回调获取传输任务；

对xPeer端按照策略进行调度，实现文件的传输；

为xPeer提供具体的传输任务，接收xPeer传输信息；

向MFS返回进度状态；

传输任务优先级处理，也就是任务的调度；

对传输任务的干预，如暂停任务、停止任务；

传输任务的监控，初期不会实现管理(比如重试等)功能；

对系统进行配置。

本实施中，调度策略如下：

1、任务调度

当MFS上发起一个任务时调用Xfer上的任务发起接口，Xfer解析任务中预计执行时间(preStartTime)为任务分配不同级别(优先级)。M-Peer根据系统配置中的调度间隔时间去发现Xfer中哪些任务需要被启动，并按照预计执行时间和优先级分别启动任务。首先以执行时间为启动任务的最基本要素，如果在同一执行时间上，以优先级高低为判断基准。

2、任务启动后的xPeer调度

任务启动后，Xfer解析任务中源端和目的端信息，通过任务中包含的源端所在应用系统和目的端所在应用系统，如果源端和目的端不在同一应用系统，分别查询源端和目的端所在应用系统已经在M-Peer注册的xPeer的状态，根据如下策略进行xPeer的任务分配：

判断源端(发送端、服务端)状态为“服务端空闲”或者服务端的连接数小于系统设置的服务端最大连接数，则依次按照服务端空闲、服务端连接数最小、服务端连接数次小的顺序选择作为服务端的xPeer；

判断目的端(接收端、客户端)状态为“客户端空闲”的xPeer做为客户端xPeer，如果出现多个状态为“客户端空闲”的xPeer，查看其作为服务器端时的客户端连接数，按照这个数量的从低到高的顺序依次选择xPeer(减低xPeer压力)，如果出现此数值相等的xPeer，则随机选择其中一个作为客户端xPeer；

选择完做传输的xPeer后，即开始文件传输。

(注：如果源端和目的端所在同一个应用系统，则不采用通过xPeer传输而是采用同一个子网内的文件拷贝模式，提高整个系统架构中文件传输效率)

本实施例中，M-Peer具有对外接口和对内接口。

M-Peer对外接口供MFS回调，主要提供启动传输任务、暂停传输、停止传输、任务优先。下面逐个介绍各对外接口。

任务发起接口(下文中的代码均是以java风格表示)：

public String startTransfer(String taskInformation)；

功能：MFS上发起一个任务时调用Xfer上的任务发起接口。

参数：taskInformation任务信息，包含该任务在mfs的实例ID、该任务在mfs上被创建的时间、发送方所在应用系统、接受方所在应用系统、源端文件名、源端路径信息、目标端存储路径、预计执行时间。

参数taskInformation格式定义(XSD)：

<？xml version＝＂1.0＂encoding＝＂UTF-8＂？>

<schema xmlns＝＂http://www.w3.org/2001/XMLSchema＂

  elementFormDefault＝＂qualified＂>

    <element name＝＂taskInformation＂>

      <complexType>

        <sequence>

          <element name＝＂mfsinstanceID＂type＝＂string＂/>

          <element name＝＂mfscreatetime＂type＝＂datetime＂/>

          <element name＝＂fromdn＂type＝＂string＂/>

          <element name＝＂todn＂type＝＂string＂/>

          <element name＝＂resourceFilename＂type＝＂string＂/>

          <element name＝＂resourceFilePath＂type＝＂string＂/>

<element name＝＂targetStorePath＂type＝＂string＂/>

          <element name＝＂preStartTime＂type＝＂datetime＂/>

        </sequence>

      </complexType>

    </element>

  </schema>

返回值：返回的内容为一个XML的字符串，任务的信息解析。

任务暂停接口：

public String pauseWorkitems(string itemID)；

功能：暂停Xfer上发起的正在进行的传输任务。

参数：itemID任务ID；

返回值：若返回零长度字符串则表示暂停任务成功，否则返回包含错误消息的XML。

任务终止接口：

public String stopWorkitems(string itemID)；

功能：终止Xfer上发起的传输任务。

参数：itemID任务ID；

返回值：若返回零长度字符串则表示终止任务成功，否则返回包含错误消息的XML。

任务优先接口：

public String prioritizeWorkitems(String itemID，Int priorityLevel)；

功能：通过对任务的优先级别进行更改的方式，优先某传输任务。

参数：itemID任务ID，priorityLevel任务的优先级信息；

返回值：若返回零长度字符串则表示优先任务成功，否则返回包含错误消息的XML。

M-Peer对内接口采用Web Service发布，主要指与xPeer的交互部分；由M-peer提供，xPeer调用，主要有xPeer的注册登记、xPeer状态汇报、xPeer文件传输进度汇报和任务状态汇报。下面逐个介绍各对内接口：

xPeer注册登记接口：

public String peerRegister(String hostIP)；

功能：向M-Peer注册xPeer本身状态。

参数：hostIP表示xPeer所在IP。

返回值：若返回零长度字符串则表示注册成功，否则返回包含错误消息的XML。

xPeer状态汇报接口：

public String reportPeerstatus(String hostIP，String peerStatus)；

功能：xPeer向Xfer汇报自身状态信息；

参数：hostIP表示xPeer所在IP地址，peerStatus表示目前xPeer的状态；

返回值：若返回零长度字符串则表示汇报成功，否则返回包含错误消息的XML。

xPeer任务进度接口：

public String postProcess(String itemID)；

功能：xPeer向M-Peer汇报文件传输进度；

参数：itemID表示任务ID；

返回值：返回该Peer上某传输任务的传输进度值。

xPeer任务状态汇报接口：

public String reportTaskStatus(String itemID)；

功能：各个xPeer通过WebService的方式向Xfer汇报文件传输进度。

参数：itemID表示任务ID；

返回值：返回该Peer上某传输任务的状态。

本实施例中，M-Peer的系统流程(参考图4)如下：

1)Xfer启动后，接受传输服务端xPeer的注册和注销；

2)M-Peer即时监听任务，如果任务不被停止，执行任务，并汇报任务状态。

本实施例中，M-Peer的调度流程(参考图5)如下：

1)当M-Peer监听到任务时，根据任务优先级发起传输任务；

2)判断任务xPeer的位置，获取执行该传输任务的xPeer的状态，如果xPeer准备就绪，发送任务到该xPeer；

3)当任务到达xPeer时，判断是否有干预指令，如果有指令(暂停、恢复、停止)执行相关干预动作；若没有干预指令，M-Peer接受xPeer状态和进度汇报，判断有无异常，若有异常，返回异常，结束任务；若无异常，实时接受xPeer汇报状态和进度数据，判断任务是否完成，若完成，结束任务，返回传输结果；若未完成，返回指令错误；

4)如果判断任务xPeer的位置，获取执行该传输任务的xPeer的状态时，xPeer准备未就绪，判断该任务的重试次数，如果超过系统配置的最大重试次数，返回异常，结束任务，如果未达到重试次数，获取任务xPeer状态，继续传输流程。

本实施例的基于总线的文件传输方式采用文件传输命令在Xfer中的封装，对外提供简单接口；传输是由Xfer自己完成，应用系统只需要将相关信息传递给Xfer，Xfer对传输任务和传输端点(xPeer)进行调度，完成传输。如图6所示，该图为Xfer调度应用系统B传输文件到应用系统C。

如果继续增加应用系统，只需应用系统上的传输端向Xfer注册一次，即可完成系统的无缝插入，体现基于总线式的架构模式，其优点是不需要在应用系统内增加客户端和服务端程序；当增加系统应用时不影响其他应用系统的工作，也不会增加整个系统的运行负担和运行成本(如图7所示)。

另外，本实施例中的主干网还包括一个内建的小型Cache盘阵。用于支持文件数据的异步传输。即任务发起时，M-Peer的调度模块发现目标系统已经离线，可将企业媒体文件传输到Cache中缓存，当目标网络恢复连线后，再将缓存的企业媒体文件传输到目的端，以减少板块间由于网络故障造成的负载增长。当然，如果源网络和目的网络均为活动状态时，文件数据将直接在两个板块之间进行传输。

由于企业媒体数据的数据量较大，因此即使在宽带网络环境下传输，仍然要耗费大量的时间。因此，本实施例中，还可以通过在板块网络中部署多个xPeer的方式，建立板块间的多条传输通道，以满足大数据量传输的需求。

当前国内外广电行业在信息化方面的总体发展方向是：网络化、信息化。本实施例采用企业媒体总线，能够让媒体文件在电视台内部各个板块直接能够进行快速、合理交换，降低劳动成本，提高节目生产效率，保证节目快速、准时、准确的进行播出，提高节目生产播出安全性。

本发明还提供一种快速文件传输协议，该协议是一种自定义的基于TCP/IP的简单文件传输协议(SimpleFTP)。SimpleFTP的程序包包括命令模块、文件查验模块、数据传输模块、完整性验证模块和错误重传模块等功能模块。

本实施例中，各板块网中的节点之间进行文件传输时，都是首先通过所在板块网中的xPeer进行Xfer封装，然后利用SimpleFTP协议在各板块网之间传输文件数据。

在SimpleFTP协议中，文件提供者称为服务端，文件获取者称为客户端。客户端发送消息之后，服务端要返回消息对应的应答消息。

本实施例中，SimpleFTP协议的消息以及其应答的格式均为统一格式：每个消息都包括两个部分，消息头和消息体。

1.消息头内容

消息头的包含内容包括以下几个部分：

日期：本条消息的时间戳；

消息ID：本条消息的ID；

加密算法：消息内容如果是加密的，在这个地方指明使用的加密算法；

长度：消息内容的长度。

2.消息体的内容

登录消息的消息体内容包括以下几个部分：

密码：登录用户的密码；

用户名：登录用户的名字。

登录应答消息的消息体内容包括以下几个部分：

登录结果：成功或者失败的标识；

用户ID：用户的会话ID，在整个传输过程中有效。

获取文件信息消息的消息体包括：

远程文件名：需要查验的远程文件的文件名。

获取文件信息消息的服务应答消息的消息体包括：

远程文件是否存在的标识；

远程文件如果存在，还给出该文件的大小(即该文件的容量)。

传送文件消息的消息体包括以下部分：

远程文件名：需要传送的远程文件的文件名；

远程文件名的起始位置：从文件的某一个起始点开始传送；

远程文件名的结束位置：从文件的某一个结束点，传送结束传送文件消息的服务应答消息包括：

启动传送进程是否成功的标识。

注销消息的消息体包括：

会话ID：用户登录时，系统分配的会话ID。

注销应答消息的消息体包括：

注销结果：成功或者失败的标识。

基于所述SimpleFTP协议的文件传输过程如下(参考图8)：

1)命令：通过登录消息在客户端登陆，向服务端发送获取文件信息消息，该消息中携带需要验证的远程文件的文件名。

2)文件查验：服务端返回服务应答消息，该应答消息中携带所述远程文件的数据量大小的信息；

3)命令：客户端根据文件的数据量大小，将文件分为多个数据段，多个数据段分为多次进行传输，设定每次文件传输的起始点和结束点，每次文件传输，客户端都向服务端发送一次传送文件消息；

4)数据传输：服务端收到传送文件消息后，开始进行本次数据传输；

5)完整性验证：客户端在接收完本次传输的数据段后，对该数据段进行完整性验证；如通过完整性验证，则回到步骤3)继续传输下一个数据段，直到所述远程文件传输完毕；

6)错误重传：当本次传输的数据段未能通过完整性验证时，客户端重新发送传送文件消息，请求重新传输该数据段。

其中，步骤5)的验证算法可以选择使用MD5算法或CRC算法。在实际应用中，常常使用的是MD5算法。但值得注意的是，本发明并不限定于这两种算法。

本实施例中，SimpleFTP协议需要对一些参数进行配置，对协议的配置包括以下几个方面：

文件读取的配置：读写文件的各类参数；而每次读、写的缓存最好在512KB以上。

网络传送的配置：网络数据包的大小等等；网络数据包大小(缓存)应该在64KB以上；

验证算法的配置：验证算法的选择，验证算法包的大小；

协议自身特性配置：是否支持断点续传，是否在传输之前进行文件验证。

一般情况下，在100Mb环境，以本协议进行文件传输可以达到8MB/sec以上的速度。

采用本发明的SimpleFTP协议，可以方便的组织、管理和调度文件传输的过程；能够提高文件传输的安全性。同时，该协议还能够很好地支持错误文件块的重传。

安全性：通常的FTP协议在传送过程中，不能保证数据在传送过程中不发生变化，本发明的SimpleFTP协议在传输的同时，还对数据进行摘要计算和验证，保证了数据传输的安全性。

错误文件块的重传：通常的FTP协议如果传输失败，则需要重新传输整个文件。本发明的SimpleFTP协议在传输过程中，如果某个文件块传输失败，我们在最后传输完成后，只对这个文件块重新进行传输。

下面详细描述本发明所采用的完整性验证方法。

在传输过程中，在正常的情况下，本实施例的服务器端(即数据发送端)需要做的工作如下：读取本地的物理文件的内容到内存；使用指定的完整性算法，计算内存中的数据的消息摘要；将数据和数据消息只要发送到网络。

本实施例的客户端(即数据接收端)需要做的工作如下：接受来自网络的数据传输；使用指定的完整性算法，验证接收到的数据；将验证成功的数据写入本地的物理文件。

本实施例首先需要对文件进行分块。对文件分块的每一块大小，要同时考虑网络、摘要、硬盘的各种要素。从整体上来讲，子文件块的数据量大小最好是256的整数倍，且子文件块的数据量必须大于读取文件块大小和读取网络块大小。(其中读取文件块就是把文件读到内存中的一次操作，比如10M的文件，如果申请了1M的内存，每次读到内存中后，处理完毕后，再次从文件中读1M的内容，连续读10次；读取网络块是指把网络数据包读到内存当中的一次操作)在分块完毕后，对文件的读、写操作，对网络的收、发操作，对内容的摘要、验证操作，每一种操作都是以文件块作为操作单位，所以文件分块的方式和每一块的大小直接影响了传输、验证的效率。

图9是本实施例的流程图，该图示出了在完成文件分块后，基于子文件块进行文件传输的详细流程，简要描述如下：

a)开始文件传输，选择一子文件块；

b)判断是否需要对文件进行验证，如果判断为是，则对该子文件块进行MD5编码，并将所得MD5编码传输给客户端，同时将该子文件块也传输给客户端；如果判断为否，则只需将子文件块传输给客户端即可；

c)在客户端接收到子文件块后，再次判断是否需要对文件进行验证，如果判断为否，则回到步骤a)，选择下一个子文件块进行传输；如果判断为是，则对接收到的子文件块重新进行MD5编码，然后判断该MD5编码与接收到的MD5编码是否一致，当编码一致时，当前子文件块通过校验，回到步骤a)，选择下一个子文件块进行传输，当编码不一致时，则重新传输当前子文件块。

不断重复上述过程，直至待传输文件的所有子文件块均传输完毕。

另外，可以为重新传输子文件块设置一个最大次数，当一个子文件块重传次数达到最大次数时，舍弃该子文件块。

下面结合实验数据，进一步分析本实施例的文件分块方式及每一块的大小对传输、验证的效率的影响。

实验平台的配置以及操作系统如下：

服务端：Windows 2003 Server 3G Cpu 1G内存 千兆网卡

客户端：Windows 2003 Server 3G Cpu 1G内存 千兆网卡

测试素材为10G的AVI文件

关于读取文件的测试参数。在实验环境下，使用EMC cx500的盘阵，多次实验10G的文件，使用本实施例的方法进行文件传输，其读写速度如表1所示。

表1

 

块大小(KB)	写的速度(MB/S)(平均值)	读的速度(MB/S)(平均值)
			512	57.5	129.7
1024	86.48	138.05
			4096	99.94	35.35
8192	44.03	99.53

在实验环境下，使用EMC cx500的盘阵，多次实验1G的文件，使用本实施例的方法进行文件传输，其读写速度如表2所示。

表2

 

块大小(KB)	写的速度(MB/S)(平均值)	读的速度(MB/S)(平均值)
			1024	108.64	140.0
4096	52.89	95.95
			8192	54.43	99.75

从表1、表2中，可以看出：读写的文件越小速度越快；分块大小在

1024KB左右，读写速度最快(针对测试的EMC cx500盘阵)。

关于读取网络的测试参数。测试方式为，在千兆网的环境下，服务端向客户端不停的发送数据包，在客户端计算综合速度。测试结果如表3所示，

表3

 

客户端块大小(KB)	服务端块大小(KB)	传输速度(MB/S)(平均值)
			128	128	112.8
4096	4096	113.0
			8192	8192	113.1

可以看出，分块大小对网络传输速度的影响不大，几乎可以达到千兆网环境下的传输速度峰值。

关于验证算法的测试参数，在实验环境下，使用md5算法，对存在于内存中的块进行摘要计算。参数如下：

采用1Mbuffer时：31毫秒

采用2Mbuffer时：62毫秒

采用3Mbuffer时：110毫秒

采用4Mbuffer时：94毫秒

采用5Mbuffer时：94毫秒

采用6Mbuffer时：125毫秒

采用7Mbuffer时：141毫秒

采用8Mbuffer时：172毫秒

采用9Mbuffer时：188毫秒

其中buffer是指缓存，也就是指分块(子文件块)的大小。

可以看出：分块的大小越大，验证所需要的时间也越多；分块大小在1M--10M的范围内，所需要的时间都很短，不影响正常传送。

在传输的过程中，需要客户端、服务端同时使用相同的摘要算法，对已经传输的内容进行校验。

校验算法方面，可以对多种协议调用做了抽象，在传输协议看来，验证算法都是同一个抽象的接口。通过配置，使用者可以选择使用MD5算法还是CRC算法等等。在实际应用中，常常使用的是MD5算法。

最后所应说明的是，以上实施例仅用以说明本发明的技术方案而非限制。尽管参照实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，对本发明的技术方案进行修改或者等同替换，都不脱离本发明技术方案的精神和范围，其均应涵盖在本发明的权利要求范围当中。

Claims (8)

1.一种大容量文件传输方法，该方法基于Xfer网络构架实现，该网络构架包括通过总线连接的主干网和多个板块网；每个所述板块网包括至少一个xPeer服务器和多个应用节点，所述主干网包括M-Peer服务器；所述大容量文件传输方法包括如下步骤：

1)接收节点请求传输服务节点中的文件；

2)所述接收节点所在板块网的xPeer服务器对携带所述请求的信令进行封装，然后与所述服务节点所在板块网的xPeer服务器进行通信，在所述主干网的M-Peer服务器的调度下，将所述文件通过总线传输至所述接收节点所在板块网的xPeer服务器上；

3)所述接收节点从所在板块网的xPeer服务器获取所述文件。

2.根据权利要求1所述的大容量文件传输方法，其特征在于，所述步骤2)中，各板块网的xPeer服务器采用SimpleFTP协议进行通信，所述SimpleFTP协议的程序包包括命令模块、文件查验模块、数据传输模块、完整性验证模块和错误重传模块。

3.根据权利要求2所述的大容量文件传输方法，其特征在于，基于SimpleFTP协议的文件传输过程如下：

21)在所述命令模块，发送获取文件信息消息，该消息中携带需要验证的远程文件的文件名；

22)在所述文件查验模块，返回服务应答消息，该应答消息中携带所述远程文件的数据量大小的信息；

23)在所述命令模块，根据文件的数据量大小，将文件分为多个数据段；

24)在所述命令模块，选取一个数据段，发送传送文件消息，该传送文件消息携带所述数据段传输的起始点和结束点；

25)在所述数据传输模块，根据收到的传送文件消息进行数据传输；

26)在所述完整性验证模块，在接收完本次传输的数据段后，对该数据段进行完整性验证；如通过完整性验证，则回到步骤4)继续传输下一个数据段，直到所述远程文件传输完毕；

27)在所述错误重传模块，当本次传输的数据段未能通过完整性验证时，客户端重新发送传送文件消息，请求重新传输该数据段。

4.根据权利要求3所述的大容量文件传输方法，其特征在于，所述步骤23)中，所述每个数据段的数据量为256k的整数倍。

5.根据权利要求3所述的大容量文件传输方法，其特征在于，所述每个数据段的数据量在1M至10M的范围内。

6.根据权利要求1所述的大容量文件传输方法，其特征在于，所述文件为媒体文件。

7.根据权利要求3所述的大容量文件传输方法，其特征在于，所述步骤27)中，为重新传输所述数据段设置一个最大次数，当一个数据段重传次数达到该最大次数时，则舍弃该数据段。

8.根据权利要求3所述的大容量文件传输方法，其特征在于，所述步骤26)中，所述完整性验证的方法可以采用MD5算法或CRC算法。

Images