CN109450989A - 一种数据传输的方法、装置、设备及介质 - Google Patents

Abstract

本公开提供了一种数据传输方法，该方法包括：接收数据，数据包括消息和文件；按照预设规则，生成消息配置信息和文件配置信息，并将消息配置信息和消息绑定，文件配置信息与文件绑定；将绑定后的消息和文件发送给接收端，以使接收端根据消息标识和文件标识判断信息的类型，若为消息，则根据消息序列码返回确认信息；若为文件，则根据文件名码和首页标识确定该文件在接收端中是否已存在，若存在，则覆盖原文件，若不存在，则存储文件，根据尾页标识确定文件已传输完成，根据文件序列码返回确认信息。另外，本公开还提供了一种装置、设备和介质。通过本发明可使得消息和文件同时传输，同时可实现文件的重传、追加等功能。

Description

一种数据传输的方法、装置、设备及介质

技术领域

本公开涉及性能测试领域，尤其涉及一种数据传输的方法、装置、设备及介质。

背景技术

在依赖开源NGrinder的性能压力测试平台中，NGrinder压力测试平台涉及中央控制器Console与施压机集群Agent之间的相互通信，通信内容一般为消息或文件，并且消息和文件的传输在同一通道，由于消息和文件不含相应的标识，当消息或文件同时传输时，接收信息的一方接收到信息时并不能判断出该信息是消息还是文件，因此发送信息的一方发送消息后，接收信息的一方必须读取消息，否则会造成通信内容的错乱，即必须即发即读；另外，接收信息的一方没有反馈功能，因此发送信息的一方不能得到接收信息一方的反馈信息，并且不能得知该文件或消息的传输状况，如传输成功、传输失败等，进而不支持文件的重传；当对文件更新后再次传输时，接收端不能判断接收端的文件中那个文件为该文件对应的未更新文件，因此不能将该更新的文件替换未更新的文件。

发明内容

(一)要解决的技术问题

在性能压力测试过程中，施压机集群与中央控制器之间相互通信，通信内容为消息或文件，当消息和文件同时传输时，接收信息的一方不能识别是消息类型还是文件类型，因此不支持文件的同时传输，并且消息和文件不含相应的序列号，接收端无法返回相应的收到信息，另外，文件不含相应的标识，使得接收端无法判断是否已接收过该文件，是否要对文件进行更新覆盖已存在的文件等，传输效率差。

(二)技术方案

本公开的主要目的在于提供了一种数据传输的方法、装置、设备及介质，旨在解决压力测试平台的现有技术中不支持消息和文件同时传输、文件不能重传、不能追加等问题。

为实现上述目的，本公开第一方面提供了一种数据传输的方法，数据传输过程中发送数据的一端为发送端，接收数据的一端为接收端，该方法包括：接收数据，数据包括消息和文件；按照预设规则，生成消息配置信息和文件配置信息，并将消息配置信息与消息绑定，文件配置信息与文件绑定，消息配置信息包括消息标识以及消息序列码，文件配置信息包括文件标识、文件名码、首页标识、尾页标识以及文件序列码；将绑定后的消息和文件发送给接收端，以使接收端根据消息标识和文件标识判断信息的类型，若为消息，则根据消息序列码返回确认信息；若为文件，则根据文件名码和首页标识确定该文件在接收端中是否已存在，若存在，则覆盖原文件，若不存在，则存储文件，根据尾页标识确定文件已传输完成，根据文件序列码返回确认信息。

可选地，将消息配置信息和所述消息绑定，将文件配置信息与文件绑定，具体包括：将消息配置信息设于消息的头部，将文件配置信息设于文件的头部。

可选地，根据文件名码和首页标识确定该文件在接收端中是否已存在，若存在，则覆盖原文件，若不存在，则存储文件，具体包括：根据文件的首页标识确定文件的首页；根据文件名码判断接收端中是否包括相同文件名的文件，若包括，则将已存在的文件删除，若不包括，则将文件存入接收端。

可选地，采用不同的type值定义消息标识和文件标识。

可选地，采用requestId对消息和文件进行序列标识，生成消息序列码和文件序列码。

可选地，根据文件序列码返回确认信息包括：提取文件配置信息中的文件序列码或消息配置信息中的消息序列码；以使发送端根据所述文件序列码确定对应的文件已传输完成或根据所述消息序列码确定对应的消息已传输完成。

可选地，首页和尾页标识由两位数的数组组成，其中，第一位数用于定义首页与非首页，第二位数用于定义尾页与非尾页。

本公开第二方面提供了一种数据传输的装置，其特征在于，装置包括：接收模块，用于接收数据，数据包括消息和文件；配置信息生成模块，用于按照预设规则，生成消息配置信息和文件配置信息，并将消息配置信息和消息绑定，文件配置信息与文件绑定，消息配置信息包括消息标识以及消息序列码，文件配置信息包括文件标识、文件名码、首页标识、尾页标识以及文件序列码；发送模块，用于将绑定后的消息和文件发送给接收端，以使接收端根据消息标识和文件标识判断信息的类型，若为消息，则根据消息序列码返回收到消息；若为文件，则根据文件名码和首页标识确定该文件在接收端中是否已存在，若存在，则覆盖原文件，若不存在，则存储文件，根据尾页标识确定文件已传输完成，根据文件序列码返回确认信息。

本公开第三方面提供了一种电子设备，包括：处理器；存储器，其存储有计算机可执行程序，程序在被处理器执行时，使得处理器执行如上所述的数据传输方法。

本公开第四方面提供了一种计算机可读存储介质，其上存储有计算机程序，其特征在于，程序被处理器执行时实现如上所述的数据传输方法。

(三)有益效果

本公开首先通过对消息和文件进行标识，使接收数据的一方可根据该标识判断该文件是消息还是文件，进而将其存入对应的存储区，另外，对文件的首页和尾页进行了标识，对文件的名称进行了编码，使得接收端可根据接收到的文件的首页标识和文件的名称编码判断该文件是否已存在，进而作出存储该文件或覆盖已存在文件的决定，另外对消息和文件设定了相应的序列码，保证消息和文件的唯一性，并且接收端可根据该序列码准确的返回收到信息，保证接收端和发送端的有效通信。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性的示出了本公开第一实施例中数据传输方法流程图；

图2示意性的示出了本公开第一实施例中的消息配置信息结构图；

图3示意性的示出了本公开第一实施例中的文件配置信息结构图；

图4示意性的示出了本公开第二实施例中的数据传输装置的框图；

图5示意性的示出了本公开第三实施例中的电子设备的框图。

具体实施方式

本公开实施例第一方面提供了一种数据传输的方法，该方法用于压力测试过程中，施压机集群与中央控制器相互之间进行数据的发送和接收，其中，发送数据的一端为发送端，接收数据的一端为接收端，数据的类型一般为消息或文件，在数据传输的过程中，首先发送端将所述数据按照预设的规则生成消息配置信息和文件配置信息，并将该消息配置信息和消息绑定，将文件配置信息与文件绑定，其中该消息配置信息包括消息标识以及消息序列码，该文件配置信息包括文件标识、文件名码、首页标识、尾页标识以及文件序列码；将绑定后的消息和文件发送给接收端，以使接收端根据消息标识和文件标识判断信息的类型，若为消息，则根据消息序列码向发送端返回收到消息；若为文件，则根据文件名码和首页标识确定该文件在接收端中是否已存在，若存在，则覆盖原文件，若不存在，则存储该文件，根据尾页标识确定文件已传输完成，当接受端收到尾页标识后根据文件序列码向发送端返回确认信息。

为了使本技术领域的人员更好地理解本公开方案，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行描述，显然，所描述的实施例仅仅是本公开一部分的实施例，而不是全部的实施例，基于本公开中的实施例，都应当属于本公开保护的范围。

图1示意性的示出了本公开实施例中数据传输方法流程图，有图1可知，具体包括如下步骤：

S101，接收数据，该数据包括消息和文件。

接受端获取到需要进行传输的数据，该数据包括消息和文件，其中，文件至少为一页，一般为多页。

S102，按照预设规则，生成消息配置信息和文件配置信息，并将消息配置信息和消息绑定，文件配置信息与文件绑定，消息配置信息包括消息标识以及消息序列码，文件配置信息包括文件标识、文件名码、首页标识、尾页标识以及文件序列码。

原生Netty的ChunkedFile不支持私有编码，通过改造ChunkedFile的readChunk函数实现本公开，具体为在调用原生ChunkedFile的基础上封装消息配置信息和文件配置信息，将消息配置信息绑定于消息的头部，消息由消息内容组成，通过将消息配置信息编写于消息内容的头部实现消息配置信息与消息的绑定，当接收端接收到所述消息时，可首先通过位于头部的消息配置信息完成数据的初步配置，然而，文件一般至少包括一页，通过将文件配置信息编写于文件的每一页的头部实现文件配置信息与文件的绑定。通过以上绑定，当接收端接收到数据包后，首次可通过位于消息或文件头部的配置信息对数据进行初步的类型判断，进而可针对不同类型的文件实现不能的操作，如将消息放于消息存储区、将文件放于文件存储区、判断接收端中是否已包含传输文件等。

按照预设规则生成如图2所示的消息配置信息，以及如图3所示的文件配置信息，其中，预设规则可为根据数据读取顺序定义的编码顺序，如本实施例中需要首先定义定长编码以区分各消息或文件、而后需要定义区分消息和文件的标识等等。该消息配置信息包括消息标识和消息序列码，由图2可知，本例中的消息标识采用type字段进行编写，如type＝0即为消息标识，消息序列码采用requestId进行定义，如可由aa001等数字、字母或其组合组合而成的序列号进行标识该消息的唯一性，该文件配置信息包括文件标识、文件名码、首页标识、尾页标识以及文件序列码，例如，可采用type＝1定义文件标识、通过4个字符长度的字母或数字定义文件名，采用10和01分别定义为文件的首页标识或尾页标识，具体定义如下。

为了使接收端接收到数据后更加清楚的存储、解码、使用等操作，需要对数据的类型进行区分，因此此处采用消息标识和文件标识进行区分，消息标识和文件标识可以采用不同的type值定义所述消息标识和文件标识，例如，采用type＝0定义该数据的类型为消息，其后的消息内容body即为消息序列化后的内容，采用type＝1定义该数据的类型为文件，另外，文件又分很多类型，如脚本文件、依赖库文件、参数化文件以及日志文件等，为更加详细的区分不同的文件类型，本实施例采用FileType值进一步定义不同的文件类型，如FileType＝1定义为脚本文件，FileType＝2定义为依赖库文件，FileType＝3定义为参数化文件，FileType＝4定义为日志文件等。接收端接收到数据后根据数据类型将其存储于不同的存储区，以备解码后使用。

文件类型的数据一般均有不同长度的文件名称，需要不同长度的文件名称按一定的规则进行编码生成固定长度的文件名码，例如采用fileNameLength定义固定长度为4个字节，fileNameByteArrray定义文件名称的编码结果，因此通过fileNameLength与fileNameByteArrray均可实现对任意长度的文件名称进行编码。

通过以上步骤即可对所述消息和文件进行初步定义即可生成消息或文件的header部分。

另一方面，消息或文件传输为TCP通道通信，其为一个面向连接的传输层协议，发送过程中可能会发送若干包数据，在接收端该若干包数据可能会粘成一个包，因此为了防止粘包问题的产生，需要在消息和文件首部设置一定规则的字符串或空格符，即定长编码，使得消息或文件的数据包能够区分开来，例如可采用4字节帧长度的字符串或空格符进行区分，其定义如下：

//首部添加4字节帧长度

pipeline.addLast(new ThorLengthFieldPrepender(intlengthFieldLength))；

lengthFieldLength＝4；

其中，pipeline为文件或消息的管道，ThorLengthFieldPrepender()为定长编码器的名称，lengthFieldLength用于定义定长编码的字节长度。

该定长编码可通过Netty中的定长编码器实现，当接收端接收到该消息或文件后采用Netty中的定长解码器对该定长编码进行解码，解码过程如下：

//定长解码器

pipeline.addLast(new ThorLengthFieldBasedFrameDecoder())；

其中，ThorLengthFieldBasedFrameDecoder()为定长解码器的名称，括号内用于加载解码内容。

通过以上操作即可成功解决数据传输过程中的粘包问题，实现数据有效传输。

若数据类型为文件，仅定义文件名称和文件类型，并不能完全表征文件的唯一性，另外，当接收端接收文件过程中并不能判断该文件是否传输成功，虽然通过文件名码可以得知该文件是否已存在，但是文件名码存在于文件的每一页中，并不能得知具体调用那一页的文件名，因此需要进一步定义文件的首页和尾页，采用首页标识和尾页标识标记文件的首页和尾页，具体如下。

当文件传输过程中，首页首先到达接收端，因此可通过首页标识使接收端根据首页中的文件名码及时判断接收端中是否已存在相同的文件，若不存在，则直接根据文件类型将其存储于接收端中相应的存储区中，若存在，则将原文件删除后将该文件存储于相应的存储区，由此可实现文件的更新；当接收端接收到尾页标识时，由于尾页标识标记该文件的尾页，证明该文件已传输完成，即可关闭文件句柄，释放资源。

其中，在文件输入或输出的过程中，需要读取文件数据，应用程序首先要调用操作系统函数如读取文件数据的readChunk等，传输文件名，并选择一个到该文件的路径来打开文件，该函数取回一个顺序号，该顺序号即为文件句柄；当要读取文件中的数据时，需要采用调用文件读取函数(ReadFile)，根据文件句柄得到相应的文件，当调用完成后，可通过调用信息函数来关闭该文件。

可采用两位数的数组fileBeginEendFlag定义文件的首页标识和尾页标识，其中，第一位数用于定义文件的首页与非首页，第二位数用于定义文件的尾页与非尾页，例如第一位数为1表示为首页，为0则表示为非首页，第二位数为1表示为尾页，为0则表示为非尾页，采用此数组即可表示该页为首页、该页为尾页或该页即为首页又为尾页等多种情况。

为保证数据传输的有效性，当消息或文件传输成功后，接收端需要向发送端发送确认信息，因此需要对文件或消息进一步生成唯一的序列码，采用requestId对所述消息和文件进行序列标识，生成消息序列码和文件序列码。

接收端在收到尾页标识endFlag后确定该文件或消息已传输完成，采用随机读取函数ThorRandomAccessFile提取文件配置信息或消息配置信息中的文件序列码或消息序列码，将文件序列码或消息序列码requestId添加至确认信息FileFinshedAckMessage中，通过信息发送函数FileTransferAckMessage将该确认信息由接收端发至发送端，以使发送端可根据文件序列码或消息序列码确定对应的文件或消息已传输完成，返回确认信息编码如下：

至此，消息配置信息与文件配置信息定义完毕。

S103，将绑定后的消息和文件发送给接收端，以使接收端根据消息标识和文件标识判断信息的类型，若为消息，则根据消息序列码返回收到消息；若为文件，则根据文件名码和首页标识确定该文件在接收端中是否已存在，若存在，则覆盖原文件，若不存在，则存储文件，根据尾页标识确定文件已传输完成，根据文件序列码返回确认信息。

发送端将绑定过消息配置信息和文件配置信息的消息和文件发送给接收端，接收端首先根据消息配置信息或文件配置信息中的消息标识和文件标识判断信息的类型，若为消息，则直接将消息序列码添加至确认信息中，并将该确认信息发送至发送端，发送端根据该消息序列码得知该消息已成功传输，若为文件，则根据文件首页标识确认该页为首页，进一步根据首页中的文件名码判断该接收端中是否存在相同的文件，若不存在，则直接将该文件存储于预定的该文件的存储区，若存在，则将原文件删除后再存储该文件，可实现文件的更新；当接收端接收到尾页标识时，确定该文件已完成，向发送端发送附有文件序列码的确认消息，完成文件的传输。

由此可知，由于消息和文件均包含消息标识和文件标识，并且定义代表消息和文件唯一性的消息序列码和文件序列码，即使消息和文件同时传输，接收端也能清晰的区分消息和文件，因此本公开支持消息和文件的同时传输。

当接收端接收到发送端发送的数据后，首先通过上述定长解码器解码所述定长编码，实现数据包与数据包之间的区分，进而通过消息头部的消息配置信息中的消息标识或文件头部文件配置信息中的文件标识，判断该数据包是消息还是文件，若为消息则直接对消息内容body进行反序列化编码，生成Java对应的消息，若为文件类型，则对文件内容body进行解码之前还需要进行如下操作：

基于上述设计，本公开还支持多任务同时下发施压机集群中的同一台施压机，每个任务可能包括若干上述的消息或文件，首先通过在施压机中建立不同的通道，并将每个任务的标识ID与通道channel的ID一一绑定，后续得到文件下发消息或文件时可通过消息或文件所属的通道channel得到任务的ID值value，可通过编码如getValue()＝＝channel实现。进而在同一台施压机中，得到任务的ID后对任务进行进一步区分消息或文件类型，可以实现对消息和文件清楚的区分、存储、读取等。即可实现不同任务同时传输而且不会出现混乱，更不会出现任务内容的混乱。

当有多任务同时下发时，文件的重传过程中，首先需要得到所属的任务ID，进一步接收端首先接收到文件的首页，通过首页标识(如10)判断接收的当前页是否为首页，若为首页，则进一步判断首页头部的文件配置信息中的文件名码判断在接收端的数据库中是否存在相同的文件，若不存在，则证明接收的该文件为新文件，则直接将其存储于接收端相应文件的存储区，若存在，则首先需要通过删除文件函数file.delete()，将原来的函数删除后，将接收的该文件存储于相应的文件存储区。

当接收端接收到文件后，采用定长解码器对文件的定长编码解码后，需要进一步对文件的内容进行解码，例如，可采用随机文件打开方式RandomAccessFile对接收到的文件进行解码，通过上述步骤判断文件是否已存在并将其追加至本地存储区，若发送过程中出现断网等意外情况使得传输中断，接收端不能接收到文件尾页标识，进而不能确定该文件已传输完成，此时接收端会向发送端发送传输失败信息FileTransferAckMessage.ERROR，当接收端接收到所述传输失败信息后，将文件进行重新传输。

本公开实施例第二方面提供了一种数据传输的装置，如图4所示，该信息传输的装置可内置于发送端与接收端中，用于执行上述图1所示的信息传输方法，该装置包括：接收模块401，配置信息生成模块402以及发送模块403。

具体的，接收模块401，用于接收数据，数据包括消息和文件；配置信息生成模块402，用于按照预设规则，生成消息配置信息和文件配置信息，并将消息配置信息和消息绑定，文件配置信息与文件绑定，消息配置信息包括消息标识以及消息序列码，文件配置信息包括文件标识、文件名码、首页标识、尾页标识以及文件序列码；发送模块403，用于将绑定后的消息和文件发送给接收端，以使接收端根据消息标识和文件标识判断信息的类型，若为消息，则根据消息序列码返回收到消息；若为文件，则根据文件名码和首页标识确定该文件在接收端中是否已存在，若存在，则覆盖原文件，若不存在，则存储文件，根据尾页标识确定文件已传输完成，根据文件序列码返回确认信息。

可以理解的是，接收模块401，配置信息生成模块402以及发送模块403可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本发明的实施例，接收模块401，配置信息生成模块402以及发送模块403中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以以对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式的适当组合来实现。或者，接收模块401，配置信息生成模块402以及发送模块403中的至少一个可以至少被部分地实现为计算机程序模块，当该程序被计算机运行时，可以执行相应模块的功能。

本公开实施例第三方面提供了一种电子设备，如图5所示，电子设备500包括处理器510及存储器520。该电子设备500可以执行上述参考图1描述的方法，以进行数据处理。

具体地，处理器510例如可以包括通用微处理器、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器510还可以包括用于缓存用途的板载存储器。处理器510可以是用于执行参考图1描述的根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

存储器520，例如可以是能够包含、存储、传送、传播或传输指令的任意介质。例如，可读存储介质可以包括但不限于电、磁、光、电磁、红外或半导体系统、装置、器件或传播介质。可读存储介质的具体示例包括：磁存储装置，如磁带或硬盘(HDD)；光存储装置，如光盘(CD-ROM)；存储器，如随机存取存储器(RAM)或闪存；和/或有线/无线通信链路。

存储器520可以包括计算机程序521，该计算机程序521可以包括代码/计算机可执行指令，其在由处理器510执行时使得处理器510执行例如上面结合图1所描述的方法流程及其任何变形。

计算机程序521可被配置为具有例如包括计算机程序模块的计算机程序代码。例如，在示例实施例中，计算机程序521中的代码可以包括一个或多个程序模块，例如包括521A、模块521B、……。应当注意，模块的划分方式和个数并不是固定的，本领域技术人员可以根据实际情况使用合适的程序模块或程序模块组合，当这些程序模块组合被处理器510执行时，使得处理器510可以执行例如上面结合图1所描述的方法流程及其任何变形。

本公开第四方面提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

根据本公开的实施例，计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、有线、光缆、射频信号等等，或者上述的任意合适的组合。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本发明所必须的。

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种数据传输方法，数据传输过程中发送数据的一端为发送端，接收数据的一端为接收端，其特征在于，所述方法包括：

接收所述数据，所述数据包括消息和文件；

按照预设规则，生成消息配置信息和文件配置信息，并将所述消息配置信息与所述消息绑定，所述文件配置信息与所述文件绑定，所述消息配置信息包括消息标识以及消息序列码，所述文件配置信息包括文件标识、文件名码、首页标识、尾页标识以及文件序列码；

将绑定后的所述消息和文件发送给所述接收端，以使所述接收端根据所述消息标识和文件标识判断所述信息的类型，若为消息，则根据所述消息序列码返回确认信息；若为文件，则根据所述文件名码和首页标识确定该文件在所述接收端中是否已存在，若存在，则覆盖原文件，若不存在，则存储所述文件，根据所述尾页标识确定文件已传输完成，根据所述文件序列码返回确认信息。

2.根据权利要求1所述的数据传输方法，其特征在于，所述并将所述消息配置信息和所述消息绑定，所述文件配置信息与所述文件绑定，具体包括：

将所述消息配置信息设于所述消息的头部，将所述文件配置信息设于所述文件的头部。

3.根据权利要求1所述的数据传输方法，其特征在于，所述根据所述文件名码和首页标识确定该文件在所述接收端中是否已存在，若存在，则覆盖原文件，若不存在，则存储所述文件，具体包括：

根据所述文件的首页标识确定文件的首页；

根据所述文件名码判断所述接收端中是否包括相同文件名的文件，若包括，则将已存在的文件删除，若不包括，则将所述文件存入所述接收端。

4.根据权利要求1所述的数据传输方法，其特征在于，采用不同的type值定义所述消息标识和文件标识。

5.根据权利要求1所述的数据传输方法，其特征在于，采用requestId对所述消息和文件进行序列标识，生成所述消息序列码和文件序列码。

6.根据权利要求5所述的数据传输方法，其特征在于，所述根据所述文件序列码返回确认信息包括：

提取所述文件配置信息中的文件序列码或所述消息配置信息中的消息序列码；

将所述文件序列码或消息序列码添加至所述确认信息中，以使所述发送端根据所述文件序列码确定对应的文件已传输完成或根据所述消息序列码确定对应的消息已传输完成。

7.根据权利要求1所述的数据传输方法，所述首页和尾页标识由两位数的数组组成，其中，第一位数用于定义首页与非首页，第二位数用于定义尾页与非尾页。

8.一种数据传输的装置，其特征在于，所述装置包括：

接收模块，用于接收所述数据，所述数据包括消息和文件；

配置信息生成模块，用于按照预设规则，生成消息配置信息和文件配置信息，并将所述消息配置信息和所述消息绑定，所述文件配置信息与所述文件绑定，所述消息配置信息包括消息标识以及消息序列码，所述文件配置信息包括文件标识、文件名码、首页标识、尾页标识以及文件序列码；

发送模块，用于将绑定后的所述消息和文件发送给所述接收端，以使所述接收端根据所述消息标识和文件标识判断所述信息的类型，若为消息，则根据所述消息序列码返回确认信息；若为文件，则根据所述文件名码和首页标识确定该文件在所述接收端中是否已存在，若存在，则覆盖原文件，若不存在，则存储所述文件，根据所述尾页标识确定文件已传输完成，根据所述文件序列码返回确认信息。

9.一种电子设备，包括：

处理器；

存储器，其存储有计算机可执行程序，所述程序在被所述处理器执行时，使得所述处理器执行如权利要求1-7中所述的数据传输方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现如权利要求1-7中所述的数据传输方法。