一种文件传输方法、终端设备及计算机可读存储介质
技术领域
本发明属于数据传输技术领域,尤其涉及一种文件传输方法、终端设备及计算机可读存储介质。
背景技术
随着计算机技术的发展,文件传输在终端设备信息交互过程中广泛应用,例如在终端设备处于***升级初始化模式时,针对升级***进行简易文件的传输。文件传输是基于一定的传输协议,将一个文件或文件中的一部分从一个终端设备传输至另一个终端设备中。
目前,传统的文件传输操作,由于在文件传输过程中,为保证传输质量,数据包以发送、等待应答的交替形式进行传输,对每发送一条数据片段均需要等待应答后,才进行下一数据片段的发送,使信道带宽不能充分利用,导致增加文件传输的耗时。
发明内容
有鉴于此,本发明实施例提供了一种文件传输方法、终端设备及计算机可读存储介质,以解决现有技术中使信道带宽不能充分利用,导致增加文件传输的耗时的问题。
本发明实施例的第一方面提供了一种文件传输方法,所述文件传输方法包括:
客户端在接收到服务端发送的文件请求回应包后,发送传输开始请求包至服务端;
客户端接收服务端发送的数据片段包,并根据所述数据片段包的信息更新客户端比特位图中相应的比特的状态,所述客户端比特位图的每个比特与文件的每个数据片段对应;
客户端在每次接收到所述数据片段包后,发送数据片段握手包至服务端,以指示服务端根据所述片段握手包的信息更新服务端比特位图中相应的比特的状态;
若所述客户端比特位图中状态更新的比特位数量与文件的数据片段的个数相等,则在预设时间内接收服务端发送的传输结束包,并进行反馈,结束文件传输。
在一个实施例中,在客户端发送传输开始请求包至服务端之前,包括:
发送文件请求包至服务端;
接收服务端发送的文件请求回应包。
在一个实施例中,客户端在接收到服务端发送的文件请求回应包后,包括:
根据所述文件请求回应包,初始化与文件对应的所述客户端比特位图,并将所述客户端比特位图的所有比特的状态设置为未发送状态,发送传输开始请求包至服务端。
在一个实施例中,客户端接收服务端发送的数据片段包,并根据所述数据片段包的信息更新客户端比特位图中相应的比特的状态,包括:
对所述数据片段包进行数据校验,并获取所述客户端比特位图中的与所述数据片段对应的比特状态值;
若所述客户端比特位图中的所述比特状态值为0,则将所述数据片段包的数据片段存储,将所述比特状态值置为1;
若所述比特状态值为1,则保持与所述数据片段对应的比特状态值不变。
本发明实施例的第二方面提供了一种文件传输方法,所述文件传输方法包括:
服务端在接收到客户端发送的文件传输开始请求包后,发送数据片段包至客户端,以指示客户端根据所述数据片段包的信息更新客户端比特位图中相应的比特的状态;
服务端接收客户端发送的数据片段握手包,根据所述数据片段握手包的信息更新服务端比特位图中相应的比特的状态,所述服务端比特位图的每个比特与文件的每个数据片段包对应;
若所述服务端比特位图中状态更新的比特位数量与文件的数据片段包的个数目相等,则在预设时间内发送传输结束包至客户端,并接收客户端反馈的传输结束包,结束文件传输。
在一个实施例中,服务端发送数据片段包至客户端之前,包括:
接收客户端发送的文件请求包;
根据所述文件请求包将文件请求回应包发送至客户端。
在一个实施例中,服务端在接收到客户端发送的文件传输开始请求包之后,还包括:
将文件划分为固定大小的若干个数据片段,每个数据片段构成一个数据片段包,并初始化与数据片段对应的服务端比特位图,将所述服务端比特位图的所有比特的状态设置为未发送状态。
在一个实施例中,服务端接收客户端发送的数据片段握手包,根据所述数据片段握手包的信息更新服务端比特位图中相应的比特的状态,包括:
遍历所述服务端比特位图中与文件的数据片段对应的比特状态值;
若所述服务端比特位图中的所述比特状态值为0,则发送对应的数据片段包,在接收到客户端发送的数据片段握手包后,将对应的所述比特状态值置为1;
若所述服务端比特位图中的所述比特状态值为1,则遍历下一数据片段对应的所述比特状态值。
本发明实施例的第三方面提供了一种终端设备,包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现上述所述文件传输方法的步骤。
本发明实施例的第四方面提供了一种计算机可读存储介质,所述计算机可读存储介质存储有计算机程序,所述计算机程序被处理器执行时实现所述文件传输方法的步骤。
本发明实施例与现有技术相比存在的有益效果是:本发明实施例客户端在接收到服务端发送的文件请求回应包后,发送传输开始请求包至服务端;客户端接收服务端发送的数据片段包,并根据数据片段包的信息更新客户端比特位图中相应的比特的状态,客户端比特位图的每个比特与文件的每个数据片段对应;通过设置比特位图,使得数据片段的传输情况得到有效标记;客户端在每次接收到数据片段包后,发送数据片段握手包至服务端,以指示服务端根据片段握手包的信息更新服务端比特位图中相应的比特的状态;若客户端比特位图中状态更新的比特位数量与文件的数据片段的个数相等,则在预设时间内接收服务端发送的传输结束包,并进行反馈,结束文件传输;使文件传输过程不需要对每发送一条数据片段均需要等待应答后,才进行下一数据片段包的发送,保证了数据片段包传输的连续性;减少了每发送一次数据片段包等待握手交互后,再进行下一数据片段包的传输所产生的耗时;提升了文件传输的速度;若服务端,客户端中的任意一方所述比特位图状态更新的比特位图的数量与对应文件的数据片段的个数相等,则客户端或服务端确认文件数据传输完成,可进入结束文件传输流程;通过设置比特位图中的比特与文件中的每个数据片段一一对应,对数据片段包的传输情况进行记录,并根据客户端比特位图或服务端比特位图的记录保证文件传输的完整性,具有较强的易用性与实用性。
附图说明
为了更清楚地说明本发明实施例中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。
图1是本发明一个实施例提供的文件传输方法应用的***结构示意图;
图2是本发明一个实施例提供的文件传输方法的实现流程示意图;
图3是本发明一个实施例提供的文件传输方法的实现流程示意图;
图4是本发明一个实施例提供的文件传输方法的交互流程示意图;
图5是本发明实施例提供的终端设备的示意图。
具体实施方式
以下描述中,为了说明而不是为了限定,提出了诸如特定***结构、技术之类的具体细节,以便透彻理解本发明实施例。然而,本领域的技术人员应当清楚,在没有这些具体细节的其它实施例中也可以实现本发明。在其它情况中,省略对众所周知的***、装置、电路以及方法的详细说明,以免不必要的细节妨碍本发明的描述。
应当理解,当在本说明书和所附权利要求书中使用时,术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在,但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
还应当理解,在此本发明说明书中所使用的术语仅仅是出于描述特定实施例的目的而并不意在限制本发明。如在本发明说明书和所附权利要求书中所使用的那样,除非上下文清楚地指明其它情况,否则单数形式的“一”、“一个”及“该”意在包括复数形式。
还应当进一步理解,在本发明说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合,并且包括这些组合。
为了说明本发明所述的技术方案,下面通过具体实施例来进行说明。
实施例一
参见图1,是本发明一个实施例提供的文件传输方法应用的***结构示意图,该文件传输方法应用于终端设备与PC主机之间的文件或者数据的传输,尤其是在终端设备开发调试阶段,通过该方法实现任意两台计算机之间的简易文件传输。如图所示,***可以包括客户终端10和服务器20,客户终端和服务器分别设置不同的线程,通过多线程并发进行数据的发送和接收,或者单线程的异步交替设计,接收和发送数据,以充分利用信道带宽,减少文件传输的耗时,提升文件传输速率;在客户终端10和服务器20分别设置与传输文件对应的比特位图,所述的比特位图为内存比特位图,通过内存比特位图对文件中的每一个数据片段进行对应标记,以记录文件的数据片段包的传输状态,在个别数据片段包暂时没有完成传输时,可以继续发送下一数据片段包,不需要等待应答后再发送下一数据片段包,从而节省文件传输的耗时;之后根据内存比特位图的标记,查找对应没有完成传输的数据片段包,进一步进行数据传输,保证文件传输的完整性。
实施例二
参见图2,是本发明一个实施例提供的文件传输方法的实现流程示意图,该文件传输方法的执行主体为实施例一中的客户终端10,如图所示,该方法包括:
步骤S201,客户端在接收到服务端发送的文件请求回应包后,通过第一线程发送传输开始请求包至服务端。
在本实施例中,在进行文件传输之前,客户端需要向服务端发送文件请求包;文件请求包是基于用户数据报协议UDP格式的数据包;服务端在接收到文件请求包后会返回文件请求回应包至客户端。其中,文件请求回应包包括文件大小以及所请求发送的文件是否存在等信息。
另外,在接收到服务端返回的文件请求回应包后,若文件请求回应包中包含与所需文件的相关信息,例如文件的名称或大小,则说明所需文件存在,则进一步通过设置的数据传输线程向服务端发送传输开始请求包。
在一个实施例中,在客户端发送传输开始请求包至服务端之前,包括:
发送文件请求包至服务端;
接收服务端发送的文件请求回应包。
在本实施例中,由客户端向服务端发送文件请求包,文件请求包中包含请求获取的文件名(File Name);在服务端接收到客户端发送的文件请求包后,会根据文件请求包中的文件名,返回与请求获取文件的相关信息,以文件请求回应包形式返回至客户端。文件请求回应包包括文件大小(File Size)、文件名称(File Name)以及文件是否存在(StatusCode)等信息。
在一个实施例中,客户端在接收到服务端发送的文件请求回应包后,包括:
根据所述文件请求回应包,初始化与文件对应的所述客户端比特位图,并将所述客户端比特位图的所有比特的状态设置为未发送状态,发送传输开始请求包至服务端。
在本实施例中,文件请求回应包中包含文件的大小信息;根据文件的大小,将文件划分为相等大小的数据片段,例如以1KB为单位,将文件划分为若干个1KB大小的数据片段,不足1KB的按实际大小为准;还可以划分为2KB或4KB大小的数据片段,具体根据***之间传输性能进行设定。客户端比特位图为客户端根据所请求文件的大小设置的内存比特位图,针对文件划分的每一个数据片段,设定与之对应的客户端比特位图的比特,客户端比特位图的比特的比特状态包括已接收到对应的数据片段和未接收到对应的数据片段;内存比特位图比特的状态值以二进制0/1进行标定,1代表已接收到状态,0代表未接收到状态。
需要说明的是,每个数据片段与内存比特位图中的每个比特建立一一对应关系;例如,以1KB为单位的数据片段包,内存比特位图的每个比特对应文件的每个KB,第N个内存比特位图的比特对应文件的第N个KB;通过对比特进行0/1标定,表示对应的数据片段包的传输状态,在客户端,0则表示未接收到相应的数据片段包状态,1则表示已接收到相应的数据片段包。
步骤S202,客户端接收服务端发送的数据片段包,并根据所述数据片段包的信息更新客户端比特位图中相应的比特的状态,所述客户端比特位图的每个比特与文件的每个数据片段对应。
在本实施例中,客户端比特位图为设置在客户端的内存比特位图,用于标记客户端接收文件的数据片段包的情况;若对应比特的状态值为0,则表示没有接收到与当前比特对应的数据片段包,需要服务端发送或再次发送与当前比特对应的数据包;若对应比特的状态值为1,则表示接收到与当前比特对应的数据片段包;无需服务端再发送;但是,为了确认数据片段已经发送,服务端依旧可以再次发送此数据片段包,此时客户端不再更新收到的数据,但总是会发出数据片段握手包。
需要说明的是,每个文件被划分为多个片段,每个片段构成一个数据片段包,由于基于用户数据报协议UDP进行文件传输,每个数据片段以基于UDP协议的数据片段包的格式进行传输;每个数据片段包包含文件数据片段(Data)、数据片段在文件中的编号(Begin)以及数据片段的大小(Size)等信息;例如,数据片段大小固定为1KB,不足1KB则以实际大小为准。
在一个实施例中,客户端接收服务端发送的数据片段包,并根据所述数据片段包的信息更新客户端比特位图中相应的比特的状态,包括:
对所述数据片段包进行数据校验,并获取所述客户端比特位图中的与所述数据片段对应的比特状态值;
若所述客户端比特位图中的所述比特状态值为0,则将所述数据片段包的数据片段存储,将所述比特状态值置为1;
若所述比特状态值为1,则保持与所述数据片段对应的比特状态值不变。
在本实施例中,客户端在接收到数据片段包后,对数据片段包进行数据校验和检查,例如校验数据片段包的大小、数据片段的准确性或数据片段的编号信息等;校验成功后,获取与数据片段包对应的在比特位图中对应的比特状态值,若比特状态值为0,则说明此次发送的与该比特对应的数据片段包为首次发送,对发送数据片段进行存储,并将对应的比特状态值更新为1,以表示已接收到该比特对应的数据片段。若获取的与此次发送的数据片段包对应的比特状态值为1,则保持对应比特状态值不做更新,但是在接收到数据包后,依然发送数据片段握手包至服务端。
步骤S203,客户端在每次接收到所述数据片段包后,发送数据片段握手包至服务端,以指示服务端根据所述片段握手包的信息更新服务端比特位图中相应的比特的状态。
在本实施例中,客户端可以不断地接收由服务端连续发送的数据片段包,在客户端每次接收到数据片段包后,发送数据片段握手包至服务端;数据片段握手包包含数据片段的编号以及数据片段的大小,以使得服务端根据数据片段握手包中的编号信息获知对应的数据片段,并更新数据片段对应的在服务端比特位图中的比特状态值。服务端比特位图为根据客户端所请求获取的文件,在服务端设置的与文件对应的内存比特位图,内存比特位图的每个比特与文件的每个数据片段的编号一一对应,通过0/1标记内存位图中的每个比特的状态值,通过与数据片段对应的比特状态值判断客户端对数据片段的接收情况。在客户端接收到数据片段包后,若与数据片段包中的数据片段对应的比特状态值为0,则存储该数据片段,并将对应的比特状态值更新为1,然后发送数据片段握手包至服务端;若与数据片段对应的比特状态值为1,则说明已经接收到该数据片段包,则直接发送数据片段握手包至服务端。
另外,通过多线程、单线程或者其它方式,客户端具备并行收发能力,客户端可以连续的接收数据片段包,同时发出数据片段握手包至服务端;在客户端接收到数据片段包后,服务端不需要等待客户端返回数据片段握手包而继续发送下一数据片段包,可以连续发送,通过内存比特位对数据片段包的发送和接收情况进行标定,进一步根据内存比特位图的标定值判断所请求获取的文件是否发送或接收完整。
基于UDP协议的数据片段包包含数据片段的编号以及大小信息;在进行文件传输时,数据将文件划分为适当固定大小的数据片段,以基于UDP协议的数据片段包的形式进行传输,使得在传输过程中具有较好的传输性能;在传输过程中,个别数据片段包暂时没有完成传输时,例如产生丢包等,可以继续传输后续的数据片段包,从而提高数据传输的连续性以及不间断性;通过内存比特位图的标定,对没有完成传输的数据片段包再次进行传输。
另外,客户端和服务端,对于当前传输的每个文件,都会设置有单独的内存比特位图与文件对应,位图的大小取决于文件大小以及文件划分的数据片段的大小,是在传输前根据文件大小设定的;一般8GB的文件,以1KB为单位划分为数据片段,则只需1MB的内存比特位图来描述,内存占用量小,不会耗用太多内存。
需要说明的是,数据片段握手包可以不按接收到的数据片段包的先后顺序返回至服务端,为保证数据传输的连续性,可以在持续接收一定数量的数据片段包后再对应每个数据片段包返回相应的数据片段握手包,不需要发送一个数据片段包得到回应后才发送下一个数据片段包,避免等待反复应答带来的额外时间开销。
步骤S204,若所述客户端比特位图中状态更新的比特位数量与文件的数据片段的个数相等,则在预设时间内接收服务端发送的传输结束包,并进行反馈,结束文件传输。
在本实施例中,客户端每接收到一个数据片段包后,检查与数据片段包的编号对应的客户端比特位图的比特状态值,若为0,则存储当前接收的数据片段包中的数据片段,并将对应的比特状态值更新为1;比特状态值为1,则表示接收到对应的数据片段;当一个文件中所有的数据片段均接收到,则与文件对应设置的内存比特的比特的状态值都为1。在服务端,接收到客户端发送的数据片段握手包后,将与数据片段对应的服务端比特位图的比特状态值更新为1,表示客户端收到该数据片段包,并通过遍历内存比特位图,若存在比特的状态值为0的,则继续发送对应的数据片段;在服务端内存比特位图的所有比特的状态值均为1时,表示服务端完成整个文件的发送。
客户端和服务端对各自的内存比特位图进行计数,比特的状态值为1的数量与文件所划分的数据片段的数量相等,则说明请求获取的文件已完整传输,此时服务端发送若干个传输结束包,以通知客户端当前文件传输结束;客户端则在随后一定时间内(例如3秒)等待服务端发来传输结束包,并将传输结束包发到服务端,服务端收到客户端回应的传输结束包后,将不再发送传输结束包,此时文件传输终止。传输结束包数量可以根据文件传输的评估值进行设定,例如可以是10个,可根据实际情况进行调整。
通过本实施例,客户端在接收到服务端发送的数据片段包后,不需要每次都成功返回数据片段握手包后,再接收下一数据片段包,可以连续的接收文件的数据片段包,提高文件传输速率的同时,保证数据片段包接收的连续性;通过在客户端和服务端设置内存比特位图,对传输过程的数据片段包的发送和接收情况进行标记,便于查询是否存在丢包情况,以保证文件传输的完整性;还可以在客户端和服务端针对某一文件的传输进行并发性设计,例如可以设置多线程或单线程异步交替,使得数据发送和接收近似同步进行(由于底层网卡驱动程序具备缓存的特性,最终可以实现收发近似并行的效果),减少每次握手交互所带来的时间开销,大幅提升文件的传输速度。服务端批量,不间断发送数据片段包,同时并发接收处理数据片段握手包;客户端批量,连续接收数据片段包,同时并发发送数据片段握手包,保证了数据包传输的连续性,批量性,充分利用信道带宽,提升了文件的传输速度。
需要说明的是,所传输的数据基于UDP协议进行传输,数据的格式都符合UDP协议的格式的规定。
需要说明的是,本领域技术人员在本发明揭露的技术范围内,可容易想到的其他排序方案也应在本发明的保护范围之内,在此不一一赘述。
应理解,上述实施例中各步骤的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。
实施例三
参见图3,是本发明一个实施例提供的文件传输方法的实现流程示意图,该文件传输方法的执行主体为实施例一中的服务器20,如图所示,文件传输方法包括:
步骤S301,服务端在接收到客户端发送的文件传输开始请求包后,发送数据片段包至客户端,以指示客户端根据所述数据片段包的信息更新客户端比特位图中相应的比特的状态。
在本实施例中,文件请求包包含文件名称;服务端在接收到客户端发送的文件传输开始请求包后,会将与文件请求包中的文件名称对应的文件划分为若干个固定大小的数据片段,将数据片段构成基于UDP协议的数据片段包;数据片段包包含数据片段的编号(Begin)、数据片段的大小(Size)以及数据片段的数据内容(Data)。客户端在接收到数据片段包后,对与数据片段包中的数据片段对应的内存比特位图进行调整。
需要说明的是,服务端可以连续的向客户端发送数据片段包,不需要每次发送完一个数据片段包,等待客户端回应后,再发送下一个数据片段包,保证了数据片段发送的连续性,减少了反复等待应答的耗时。
在一个实施例中,服务端发送数据片段包至客户端之前,包括:
接收客户端发送的文件请求包;
根据所述文件请求包将文件请求回应包发送至客户端。
在本实施例中,文件请求包包含文件的名称(File Name);文件请求回应包包含文件名称(File Name)、文件大小(File Size)以及文件是否存在的状态(Status Code)。
在一个实施例中,服务端在接收到客户端发送的文件传输开始请求包之后,还包括:
将文件划分为固定大小的若干个数据片段,每个数据片段构成一个数据片段包,并初始化与数据片段对应的服务端比特位图,将所述服务端比特位图的所有比特的状态设置为未发送状态。
在本实施例中,一个文件划分为若干个固定大小的数据片段,每个数据片段用于构成一个基于UDP协议格式的数据片段包,基于UDP协议格式的数据片段包包含文件的数据片段(Data)、数据片段在文件中的编号(Begin)以及数据片段的大小(Size)。文件按数据片段的大小进行划分,可以划分为1KB、2KB或4KB固定大小的数据片段,当数据片段大小固定为1KB时,不足1KB的数据片段以实际大小为准。基于UDP传输协议,文件在传输过程以数据片段包为单位进行传输,服务端比特位图为在服务端根据文件划分的每个数据片段设置对应的内存比特位图,以标记每个数据片段的发送情况;服务端内存比特位图中每个比特的状态值与数据片段的编号一一对应。
步骤S302,服务端接收客户端发送的数据片段握手包,根据所述数据片段握手包的信息更新服务端比特位图中相应的比特的状态,所述服务端比特位图的每个比特与文件的每个数据片段包对应。
在本实施例中,数据片段握手包包含数据片段的编号以及数据片段的大小;在服务端,服务端比特位图的比特的比特状态包括已发送对应的数据片段和未发送对应的数据片段;内存比特位图比特的状态值以二进制0/1进行标定,1代表已发送状态,0代表未发送状态。服务端根据客户端回应的数据片段握手包,更新内存比特位图中与数据片段包对应的比特的状态值,将对应的比特的状态值为调整为1;服务端依次遍历文件的每个数据片段包对应的比特的状态值,若对应的比特状态值为0,则继续发送该比特对应的数据片段,若为1,则跳过该比特位对应的数据片段。
在一个实施例中,服务端接收客户端发送的数据片段握手包,根据所述数据片段握手包的信息更新服务端比特位图中相应的比特的状态,包括:
遍历所述服务端比特位图中与文件的数据片段对应的比特状态值;
若所述服务端比特位图中的所述比特状态值为0,则发送对应的数据片段包,在接收到客户端发送的数据片段握手包后,将对应的所述比特状态值置为1;
若所述服务端比特位图中的所述比特状态值为1,则遍历下一数据片段对应的所述比特状态值。
步骤S303,若所述服务端比特位图中状态更新的比特位数量与文件的数据片段包的个数目相等,则在预设时间内发送传输结束包至客户端,并接收客户端反馈的传输结束包,结束文件传输。
在本实施例中,客户端每接收到一个数据片段包后,检查与数据片段包的编号对应的在客户端比特位图中的比特状态值,若为0,则存储当前接收的数据片段包中的数据片段,并将对应的比特状态值值调整为1;比特状态值为1表示客户端接收到对应的数据片段;当一个文件中所有的数据片段均被接收到,则与文件对应设置的客户端比特位图的比特状态值都为1。在服务端,接收到客户端发送的数据片段握手包后,将与数据片段对应的比特状态值调整为1,表示客户端收到该数据片段,并通过遍历服务端内存比特位图,若存在状态值为0的比特,则继续发送对应的数据片段包;在服务端比特位图所有比特位的状态值均为1时,表示服务端完成整个文件的发送以及客户端接收到完成的文件。
客户端和服务端对各自的内存比特位图进行计数,比特的状态值为1的数量与文件所划分的数据片段的数量相等,则说明请求获取的文件已完整传输,此时服务端发送若干个传输结束包,以通知客户端当前文件传输结束;客户端则在随后一定时间内(例如3秒)等待服务端发来传输结束包,并将传输结束包发到服务端,服务端收到客户端回应的传输结束包后,将不再发送传输结束包,此时文件传输终止。传输结束包数量可以根据文件传输的评估值进行设定,例如可以是10个,可根据实际情况进行调整。
需要说明的是,在服务端发送传输结束包至客户端后,需要在预设的时间内接收客户端返回的传输结束包,服务端确认传输结束;若服务端收不到客户端回传的传输结束包,可反复发送更多传输结束包至客户端,直到收到客户端回传的传输结束包,终止文件传输。
通过本实施例,客户端在接收到服务端发送的数据片段包后,不需要每次都成功返回数据片段握手包后,再接收下一数据片段包,可以连续的接收文件的数据片段包,提高文件传输速率的同时,保证数据片段包接收的连续性;通过在客户端和服务端设置内存比特位图,对传输过程的数据片段包的发送和接收情况进行标记,便于查询是否存在丢包情况,以保证文件传输的完整性;还可以在客户端和服务端针对某一文件的传输进行并发性设计,例如可以设置多线程或单线程异步交替,使得数据发送和接收近似同步进行(由于底层网卡驱动程序具备缓存的特性,最终可以实现收发近似并行的效果),减少每次握手交互所带来的时间开销,大幅提升文件的传输速度。
需要说明的是,所传输的数据基于UDP协议进行传输,数据的格式都符合UDP协议的格式的规定。
需要说明的是,本领域技术人员在本发明揭露的技术范围内,可容易想到的其他排序方案也应在本发明的保护范围之内,在此不一一赘述。
应理解,上述实施例中各步骤的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。
实施例四
参见图4,是本发明一个实施例提供的文件传输方法的交互流程示意图,该交互过程的执行主体分别为客户端和服务端,也可以是其它任意的进行文件或数据交互的计算机;文件传输过程与图2、图3所述的文件传输原理相同,在此不再赘述。
该交互过程包括:
1、客户端向服务器发送文件请求包;
2、服务端接收到文件请求包后,向客户端发送文件请求回应包;
3、客户端根据接收的文件请求回应包设置与文件对应的客户端比特位图;
4、客户端发送传输开始请求包至服务端;
5、服务端将文件划分为固定大小的数据片段,并初始化对应的服务端内存比特位图;
6、服务端发送数据片段包至客户端;
7、客户端对数据片段包进行数据校验,更新客户端内存比特位图中对应比特的状态值;
8、客户端发送数据片段握手包至服务端;
9、服务端根据握手包调整服务端内存比特位图的对应比特的状态值;
10,在所述服务端比特位图中状态更新的比特位数量与文件的数据片段包的个数目相等,服务端发送传输结束包至客户端;
11、客户端在预设时间内若收到传输结束包,则返回传输结束包至服务端,客户端结束传输,但在预设时间内若收到传输结束包,依旧返回传输结束包至服务器。
通过本实施例,客户端在接收到服务端发送的数据片段包后,不需要每次都成功返回数据片段握手包后,再接收下一数据片段包,可以连续的接收文件的数据片段包,提高文件传输速率的同时,保证数据片段的连续性;通过在客户端和服务端设置内存比特位图,对传输过程的数据片段的发送和接收情况进行标记,便于查询是否存在丢包情况,以保证文件传输的完整性;还可以在客户端和服务端针对某一文件的传输进行并发设计,使得数据发送和接收同步进行,减少每次握手交互所带来的时间开销,大幅提升文件的传输速度。
需要说明的是,本领域技术人员在本发明揭露的技术范围内,可容易想到的其他排序方案也应在本发明的保护范围之内,在此不一一赘述。
应理解,上述实施例中各步骤的序号的大小并不意味着执行顺序的先后,各过程的执行顺序应以其功能和内在逻辑确定,而不应对本发明实施例的实施过程构成任何限定。
实施例五
参见图5,是本发明一实施例提供的终端设备的示意图。如图5所示,该实施例的终端设备5包括:处理器50、存储器51以及存储在所述存储器51中并可在所述处理器50上运行的计算机程序52。所述处理器50执行所述计算机程序52时实现上述各个文件传输方法实施例中的步骤,例如图2所示的步骤201至204,或者图3所示的步骤301至303。
示例性的,所述计算机程序52可以被分割成一个或多个模块/单元,所述一个或者多个模块/单元被存储在所述存储器51中,并由所述处理器50执行,以完成本发明。所述一个或多个模块/单元可以是能够完成特定功能的一系列计算机程序指令段,该指令段用于描述所述计算机程序52在所述终端设备5中的执行过程。
所述终端设备5可以是桌上型计算机、笔记本、掌上电脑及云端服务器等计算设备。所述终端设备可包括,但不仅限于,处理器50、存储器51。本领域技术人员可以理解,图5仅仅是终端设备5的示例,并不构成对终端设备5的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件,例如所述终端设备还可以包括输入输出设备、网络接入设备、总线等。
所称处理器60可以是中央处理单元(Central Processing Unit,CPU),还可以是其他通用处理器、数字信号处理器(Digital Signal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现成可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
所述存储器51可以是所述终端设备5的内部存储单元,例如终端设备5的硬盘或内存。所述存储器51也可以是所述终端设备5的外部存储设备,例如所述终端设备5上配备的插接式硬盘,智能存储卡(Smart Media Card,SMC),安全数字(Secure Digital,SD)卡,闪存卡(Flash Card)等。进一步地,所述存储器51还可以既包括所述终端设备5的内部存储单元也包括外部存储设备。所述存储器51用于存储所述计算机程序以及所述终端设备所需的其他程序和数据。所述存储器51还可以用于暂时地存储已经输出或者将要输出的数据。
所属领域的技术人员可以清楚地了解到,为了描述的方便和简洁,仅以上述各功能单元、模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能单元、模块完成,即将所述装置的内部结构划分成不同的功能单元或模块,以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中,上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。另外,各功能单元、模块的具体名称也只是为了便于相互区分,并不用于限制本发明的保护范围。上述***中单元、模块的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述或记载的部分,可以参见其它实施例的相关描述。
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
在本发明所提供的实施例中,应该理解到,所揭露的装置/终端设备和方法,可以通过其它的方式实现。例如,以上所描述的装置/终端设备实施例仅仅是示意性的,例如,所述模块或单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口,装置或单元的间接耦合或通讯连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明实现上述实施例方法中的全部或部分流程,也可以通过计算机程序来指令相关的硬件来完成,所述的计算机程序可存储于一计算机可读存储介质中,该计算机程序在被处理器执行时,可实现上述各个方法实施例的步骤。其中,所述计算机程序包括计算机程序代码,所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括:能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是,所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减,例如在某些司法管辖区,根据立法和专利实践,计算机可读介质不包括是电载波信号和电信信号。
以上所述实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围,均应包含在本发明的保护范围之内。