CN113835902A - 一种数据处理方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本公开提供了一种数据处理方法、装置、计算机设备及存储介质，其中，该方法包括：获取多个请求数据包；通过与目标终端进行通信协商确定多个请求数据包分别对应的第一接口调用信息，并将第一接口调用信息写入请求数据包的头部协议数据段中；基于第一接口调用信息，以及预先设置的不同接口之间的上下文关系，确定多个请求数据包的发送顺序；基于发送顺序，利用单线程通道将携带有第一接口调用信息的多个请求数据包依次发送至目标终端。本公开实施例采用单线程通道的方式对多个请求数据包进行线性发送，能够保证多个请求数据包按照接口之间的上下文关系发送到目标终端，从而可以提高数据发送的准确性。

Description

一种数据处理方法、装置、计算机设备及存储介质

技术领域

本公开涉及计算机技术领域，具体而言，涉及一种数据处理方法、装置、计算机设备及存储介质。

背景技术

在数据转发过程中，为了处理多个数据包的发送请求，往往会开启多个线程来处理数据发送业务，以提高服务的处理能力，但是如果对多个数据包的先后顺序有严格要求的情况下，多线程的数据发送方式可能会打乱数据包的先后顺序，降低数据包发送到接收端的准确性。

发明内容

本公开实施例至少提供一种数据处理方法、装置、计算机设备及存储介质。

第一方面，本公开实施例提供了一种数据处理方法，包括：

获取多个请求数据包；

通过与目标终端进行通信协商确定所述多个请求数据包分别对应的第一接口调用信息，并将所述第一接口调用信息写入所述请求数据包的头部协议数据段中；

基于所述第一接口调用信息，以及预先设置的不同接口之间的上下文关系，确定所述多个请求数据包的发送顺序；

基于所述发送顺序，利用单线程通道将携带有所述第一接口调用信息的所述多个请求数据包依次发送至目标终端。

一种可选的实施方式中，所述基于所述多个请求数据包的发送顺序，利用单线程通道将所述多个请求数据包依次发送至目标终端，包括：

基于单次发送的数据包大小，对所述请求数据包进行拆分处理，得到多个第一子数据包；所述多个第一子数据包中包括至少一个数据量与所述单次发送的数据包大小相等的目标第一子数据包；

若所述多个第一子数据包中，存在数据量小于所述单次发送的数据包大小的第一子数据包，则确定所述单次发送的数据包大小与存在的该第一子数据包的大小之间的数据量差额；

按照所述数据量差额，从与所述请求数据包相邻的下一个请求数据包中拆分出子数据包，与所述数据量小于所述单次发送的数据包大小的第一子数据包进行整合，得到数据量与所述单次发送的数据包大小相等的目标第一子数据包；

基于所述多个请求数据包的发送顺序，利用单线程通道将多个目标第一子数据包依次发送至目标终端。

一种可选的实施方式中，基于所述多个请求数据包的发送顺序，利用单线程通道将多个目标第一子数据包依次发送至目标终端，包括：

基于所述多个请求数据包的发送顺序以及各个请求数据包中第一子数据包的排列顺序，将所述多个目标第一子数据包加入到缓存队列；

从所述缓存队列中依次提取各个目标第一子数据包，并利用单线程通道将提取的目标第一子数据包依次发送至目标终端。

一种可选的实施方式中，所述将所述多个目标第一子数据包加入到缓存队列，包括：

针对每个请求数据包，判断所述请求数据包的目标第一子数据包是否全部加入缓存队列；

若所述请求数据包的目标第一子数据包全部加入缓存队列时，则基于所述多个请求数据包的发送顺序以及各个请求数据包中第一子数据包的排列顺序，将下一个请求数据包的多个目标第一子数据包加入到缓存队列。

一种可选的实施方式中，所述方法还包括：

依次接收所述目标终端利用单线程通道发送的第二子数据包；

确定所述第二子数据包中携带有头部协议数据段的目标第二子数据包；

从所述目标第二子数据包携带的头部协议数据段中解析得到所述目标第二子数据包对应的完整数据包大小；

基于所述完整数据包大小，按照各个第二子数据包的接收顺序，将所述目标第二子数据包和接收到的其它第二子数据包整合成完整的响应数据包。

一种可选的实施方式中，确定所述第二子数据包中携带有头部协议数据段的目标第二子数据包之后，从所述目标第二子数据包携带的头部协议数据段中解析得到所述目标第二子数据包对应的完整数据包大小之前，所述方法还包括：

从所述目标第二子数据包携带的头部协议数据段中解析得到所述目标第二子数据包的第二接口调用信息；

基于所述第二接口调用信息，查找本地存储的与该第二接口调用信息对应的头部协议数据段的目标信息格式；

将所述目标信息格式与所述目标第二子数据包携带的头部协议数据段的信息格式进行比对；

在比对一致的情况下，确定所述目标第二子数据包的合法性校验通过。

一种可选的实施方式中，基于所述完整数据包大小，按照各个第二子数据包的接收顺序，将所述目标第二子数据包和接收到的其它第二子数据包整合成完整的响应数据包，包括：

在按照各个第二子数据包的接收顺序，将所述目标第二子数据包和接收到的其它第二子数据包进行整合时，确定无法将整数个第二子数据包整合为与所述完整数据大小匹配的响应数据包，则对最后整合进该响应数据包的第二子数据包进行切分，以得到与所述完整数据大小匹配的响应数据包。

一种可选的实施方式中，所述方法应用于远程服务联调中，所述方法的执行主体为电脑端，所述目标终端为手机端；

所述电脑端与手机端进行通信协商确定所述多个请求数据包分别对应的第一接口调用信息之前，包括：

基于传输控制协议TCP，与所述手机端之间建立套接字socket通信连接，以便所述电脑端与所述手机端之间基于所述socket通信连接进行数据传输。

第二方面，本公开实施例还提供一种数据处理装置，包括：

获取模块，用于获取多个请求数据包；

第一确定模块，用于通过与目标终端进行通信协商确定所述多个请求数据包分别对应的第一接口调用信息，并将所述第一接口调用信息写入所述请求数据包的头部协议数据段中；

第二确定模块，用于基于所述第一接口调用信息，以及预先设置的不同接口之间的上下文关系，确定所述多个请求数据包的发送顺序；

发送模块，用于基于所述发送顺序，利用单线程通道将携带有所述第一接口调用信息的所述多个请求数据包依次发送至目标终端。

第三方面，本公开实施例还提供一种计算机设备，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当计算机设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行上述第一方面，或第一方面中任一种可能的实施方式中的步骤。

第四方面，本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述第一方面，或第一方面中任一种可能的实施方式中的步骤。

本公开实施例提供的一种数据处理方法、装置、计算机设备及存储介质，基于携带有接口调用信息的头部协议发送请求数据包，可以保证目标终端返回的响应数据包与请求数据包的接口是相对应的，从而保证响应数据的正确性，并且采用单线程通道的方式对多个请求数据包进行线性发送，能够保证多个请求数据包按照接口之间的上下文关系发送到目标终端，从而可以提高数据发送的准确性。

另外，本公开实施例的一种实施方式中，在请求数据包大于单次发送的数据包大小的时候，对请求数据包进行拆分，防止数据包过大时导致通道无法发送，并且按照请求数据包的发送顺序以及拆分后得到的第一子数据包的排列顺序，将第一子数据包进行发送，可以保证接口之间的时序性，提高数据发送的准确性。相应地，在接收到返回的第二子数据包时，根据头部协议中携带的完整数据包大小整合第二子数据包，可以保证将第二子数据包整合成一个完整的数据包，从而保证数据接收的准确性和完整性。

为使本公开的上述目的、特征和优点能更明显易懂，下文特举较佳实施例，并配合所附附图，作详细说明如下。

附图说明

为了更清楚地说明本公开实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，此处的附图被并入说明书中并构成本说明书中的一部分，这些附图示出了符合本公开的实施例，并与说明书一起用于说明本公开的技术方案。应当理解，以下附图仅示出了本公开的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1示出了本公开实施例所提供的第一种数据处理方法的流程图；

图2示出了本公开实施例所提供的第二种数据处理方法的流程图；

图3示出了本公开实施例所提供的第三种数据处理方法的流程图；

图4示出了本公开实施例所提供的一种数据处理装置的示意图；

图5示出了本公开实施例所提供的一种计算机设备的示意图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围，而是仅仅表示本公开的选定实施例。基于本公开的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。

在数据转发过程中，为了处理多个数据包的发送请求，往往会开启多个线程来处理数据发送业务，以提高服务的处理能力，但是如果对多个数据包的先后顺序由严格要求的情况下，多线程的数据发送方式可能会打乱数据包的先后顺序，降低数据包发送到接收端的准确性。

基于此，本公开提供了一种数据处理方法、装置、计算机设备及存储介质，采用单线程通道的方式对多个请求数据包进行线性发送，能够保证多个请求数据包按照接口之间的上下文关系发送到目标终端，从而可以提高数据发送的准确性。

针对以上方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及下文中本公开针对上述问题所提出的解决方案，都应该是发明人在本公开过程中对本公开做出的贡献。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

为便于对本实施例进行理解，首先对本公开实施例所公开的一种数据处理方法进行详细介绍，本公开实施例所提供的数据处理方法的执行主体一般为具有一定计算能力的计算机设备。在一些可能的实现方式中，该数据处理方法可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。

本公开实施例提供的数据处理方法可以应用于在局域网内电脑端远程调用运行在手机端的软件开发工具包(Software Development Kit，SDK)中的数据的场景中，在本公开实施例提供的数据处理方法执行之前，电脑端与手机端可以基于传输控制协议(Transmission Control Protocol，TCP)建立套接字(socket)通信连接，电脑端与手机端基于socket通信连接进行数据传输。在远程联调的场景中，电脑端与手机端建立连接后，电脑端向手机端发送请求，手机端为电脑端提供SDK的数据的服务，因此，这里可以定义电脑端为客户端，手机端为服务端。

例如，在个人电脑(Personal Computer，PC)端或苹果电脑(Macintosh，Mac)端进行游戏引擎开发时，游戏中的登录、支付、定位等能力需要依赖手机端SDK中的数据，PC/Mac端向手机端发送数据请求，手机端接收到数据请求后将SDK中的数据返回给PC/Mac端，完成局域网内跨设备的数据访问。

下面以执行主体为客户端(即电脑端)为例对本公开实施例提供的数据处理方法加以说明。

参见图1所示，为本公开实施例提供的第一种数据处理方法的流程图，所述方法包括S101～S104，其中：

S101：获取多个请求数据包。

请求数据包是远程联调场景下客户端发送的、用于请求服务端返回响应数据的数据包。请求数据包用于请求获取服务端中对应SDK接口中的返回数据，服务端中不同的SDK接口之间存在上下文关系，即时序依赖关系，因此服务端中对应SDK接口在返回响应数据时，需要根据不同的SDK接口之间存在的时序依赖关系，返回对应的响应数据。例如，客户端需要请求服务端中登录接口和支付接口的数据，支付接口的数据依赖于登录接口的数据，因此需要先返回登录接口的数据之后才能返回支付接口的数据。

客户端远程调用服务端的接口时，可以把包含接口调用和功能模块等有关的字段信息转换成基于文本的数据交换格式，从而得到请求数据包，这里的数据交换格式可以是JavaScript对象标记(JavaScript Object Notation，JSON)的数据交换格式。

这里，分别获取对应每个接口的请求数据包。为了实现服务端能够返回与请求数据包对应的接口的完整数据，在发送请求数据包之前，客户端与服务端可以基于socket通信协商定义头部协议，双端都基于此头部协议来进行数据包的收发。

S102：通过与目标终端进行通信协商确定所述多个请求数据包分别对应的第一接口调用信息，并将所述第一接口调用信息写入所述请求数据包的头部协议数据段中。

这里的目标终端可以指的是服务端。协商定义应用层头部协议之后，可以将应用层头部协议组装到请求数据包中，应用层头部协议数据段中可以包括第一接口调用信息，第一接口调用信息中可以包括接口标识、接口类型和消息类型等。

其中，每个接口都添加有唯一的接口标识，客户端和服务端可以根据接口标识准确定位到每个接口。例如客户端请求服务端中接口A的数据，服务端收到请求后会根据接口标识，确定出与该接口标识对应的接口A的数据。

接口类型指的是同步请求或异步请求的类型，同步请求是指客户端发送请求数据包后同步等待服务端返回的数据，异步请求是指客户端发送请求数据包后不需要阻塞等待服务端返回的数据。

这里，不同的请求数据包对应的第一接口调用信息是不同的。

在具体实施中，完成应用层头部协议的添加后，还可以添加网络层头部协议，网络层头部协议数据段中包括完整请求数据包的大小，以及请求数据包的类型，使得服务端可以根据头部协议数据段接收到对应的请求数据包。

S103：基于所述第一接口调用信息，以及预先设置的不同接口之间的上下文关系，确定所述多个请求数据包的发送顺序。

由于不同接口数据之间存在时序依赖关系，也就是下一个接口的数据需要依赖上一个接口的数据处理完成之后才能处理，因此这里可以根据不同接口之间的时序依赖关系，预先设置不同接口之间的上下文关系。根据第一接口调用信息中的接口标识、不同接口之间的上下文关系，就可以确定出多个请求数据包的发送顺序。

S104：基于所述发送顺序，利用单线程通道将携带有所述第一接口调用信息的所述多个请求数据包依次发送至目标终端。

正是由于不同接口数据之间的时序依赖关系，在请求数据包的发送过程中需要按照不同接口对应的请求数据包的发送顺序进行发送。单线程通道可以按照发送顺序，依次发送多个请求数据包，也就是单线程通道可以对应多个接口的请求数据包，并且在发送当前请求数据包时，不会发送其他的请求数据包，从而保证了不同接口数据之间的时序依赖关系。

在具体实施过程中，当数据包的大小超过了在发送通道中的单次发送的数据包大小时，需要对数据包进行拆分，将数据包拆分成小于或等于单次发送的数据包大小的子数据包。在一种实施方式中，基于多个请求数据包的发送顺序，利用单线程通道将所述多个请求数据包依次发送至目标终端，具体可以包括以下步骤：

步骤1：基于单次发送的数据包大小，对请求数据包进行拆分处理，得到多个第一子数据包；多个第一子数据包中包括至少一个对应的数据量与单次发送的数据包大小相等的目标第一子数据包。

这里可以加入滑动窗口等拥塞处理机制，将请求数据包拆分成多个第一子数据包，以满足单次发送的数据包大小。拆分出的第一子数据包可以放入线程的发送通道中，且拆分出的多个第一子数据包在完整请求数据包中的排列顺序与其在线程的发送通道的排列顺序是一致的。

针对数据量大于单次发送的数据包大小的请求数据包，可以拆分出至少一个数据量与单次发送的数据包大小相等的第一子数据包，这里可以将数据量与单次发送的数据包大小相等的第一子数据包定义为目标第一子数据包。

步骤2：若多个第一子数据包中，存在数据量小于单次发送的数据包大小的第一子数据包，则确定单次发送的数据包大小与存在的该第一子数据包的大小之间的数据量差额。

考虑到不同请求数据包的大小不一定等于单次发送的数据包大小的整数倍，因此，可能拆分出的多个第一子数据包中存在数据量小于单次发送的数据包大小的第一子数据包。这里，数据量小于单次发送的数据包大小的第一子数据包，通常为完整的请求数据包拆分出的多个第一子数据包中的最后一个。

步骤3：按照数据量差额，从与请求数据包相邻的下一个请求数据包中拆分出子数据包，与数据量小于数据包大小的第一子数据包进行整合，得到数据量与单次发送的数据包大小相等的目标第一子数据包。

为了保证每次发送的数据包都满足单次发送的数据包大小，因此在拆分过程还可以包括整合过程，也就是将数据量小于单次发送的数据包大小的第一子数据包与下一个拆分出来的子数据包进行整合。

这里，可以按照确定出的单次发送的数据包大小与数据量小于单次发送的数据包大小的第一子数据包之间的数据量差额，从与该请求数据包相邻的下一个请求数据包中拆分出子数据包(由于数据量小于单次发送的数据包大小的第一子数据包为该请求数据包中的最后一个子数据包，因此需要从下一个请求数据包拆分出子数据包与该第一子数据包进行整合)。

从下一个请求数据包中拆分出子数据包与数据量小于数据包大小的第一子数据包进行整合，就可以得到目标第一子数据包(数据量与单次发送的数据包大小相等)。

下一个请求数据包中拆分出子数据包后，继续判断超过了在发送通道中的单次发送的数据包大小，如果超过了，则按照上述步骤1至步骤3的过程，得到多个目标第一子数据包，直至将所有请求数据包都拆分完成。当最后一个请求数据包的最后一个第一子数据包小于单次发送的数据包大小时，可以直接放入线程的发送通道中。

步骤4：基于多个请求数据包的发送顺序，利用单线程通道将多个目标第一子数据包依次发送至目标终端。

在具体实施中，拆分请求数据包与发送目标第一子数据包可以不是同步的，因此当目标第一子数据包不断的拆分出来后，可以加入到缓存队列中，这里可以基于多个请求数据包的发送顺序以及各个请求数据包中第一子数据包的排列顺序，将多个目标第一子数据包加入到缓存队列中。在具体实施中，可以同时利用多个线程将目标第一子数据包加入到缓存队列中。

进一步地，为了保证多个目标第一子数据包的发送顺序，这里可以加入互斥锁机制。当有多个请求数据包时，每次只能对一个请求数据包的目标第一子数据包进行添加，只有该请求数据包的目标第一子数据包全部加入缓存队列后才会对下一个请求数据包的目标第一子数据包进行添加。当其中一个线程持有互斥锁后其他线程会进行休眠等待，只有持有线程释放后，其他线程才会有时机持有互斥锁，从而可以保证目标第一子数据包的发送顺序。

这里可以采用Loop机制，驱动客户端从缓存队列中依次提取各个目标第一子数据包，并利用单线程通道将提取的目标第一子数据包依次发送至目标终端。当缓存队列为空时，Loop机制会进行休眠，直到有目标第一子数据包加入缓存队列后才会再次被唤醒，以此可以实现节省资源。在具体实施中，目标第一子数据包按照缓存队列中的顺序加入二进制数据流通道，不断地通过Socket通信发送到服务端。

服务端的端口可以监听是否接收到数据包，当服务端接收到目标第一子数据包之后，可以将目标第一子数据包加入到服务端的缓存队列中，并判断对接收到的目标第一子数据包是否已读取头部协议数据，如果没有，则通过对请求数据包中的头部协议数据段进行解析，设置标志位来识别得到完整数据包大小，然后根据完整数据包大小对目标第一子数据包进行整合，得到完整的请求数据包，并调取与请求数据包对应的响应数据包返回至客户端。其中服务端将响应数据包返回至客户端的过程，与客户端向服务端发送请求数据包的过程类似，这里不再赘述。服务端接收目标第一子数据包，得到完整的请求数据包的过程与客户端接收响应数据包的过程类似，下面将仍然以客户端为执行主体，对客户端接收响应数据包的过程加以说明。

参见图2所示，为本公开实施例提供的第二种数据处理方法的流程图，所述方法包括S201～S204，其中：

S201：依次接收所述目标终端利用单线程通道发送的第二子数据包。

这里的目标终端指的是服务端(即手机端)。第二子数据包指的是响应数据包拆分之后得到的子数据包。为了保证不同接口对应的响应数据包的接收顺序，这里的第二子数据包也是采用单线程通道发送的。

S202：确定所述第二子数据包中携带有头部协议数据段的目标第二子数据包。

携带有头部协议数据段的目标第二子数据包通常是一个完整响应数据包拆分后得到的第一个第二子数据包，由于第二子数据包是单线程发送的，第二子数据包的发送顺序与第二子数据包在响应数据包中的排列顺序是一致的，因此当首次接收到第二子数据包时，可以将该第二子数据包确定为目标第二子数据包。

为了保证接收到的数据的准确性，在确定所述第二子数据包中携带有头部协议数据段的目标第二子数据包之后，从所述目标第二子数据包携带的头部协议数据段中解析得到所述目标第二子数据包对应的完整数据包大小之前，可以从目标第二子数据包携带的头部协议数据段中解析得到目标第二子数据包的第二接口调用信息，基于第二接口调用信息，查找本地存储的与该第二接口调用信息对应的头部协议数据段的目标信息格式。其中，客户端与服务端可以通过通信协商数据包中携带的头部协议。

将目标信息格式与目标第二子数据包携带的头部协议数据段的信息格式进行比对，如果目标第二子数据包携带的头部协议数据段与本地存储的头部协议数据段是通信协商的，那么目标第二子数据包携带的头部协议数据段的信息格式与本地存储的头部协议数据段的目标信息格式应当是一致的。

在比对一致的情况下，确定目标第二子数据包的合法性校验通过，此时可以执行以下步骤。

S203：从所述目标第二子数据包携带的头部协议数据段中解析得到所述目标第二子数据包对应的完整数据包大小。

这里，解析得到目标第二子数据包对应的完整数据包大小后，可以标记对应的标志位，客户端持续接收过程中可以通过标志位识别出每一个完整的数据包。

S204：基于所述完整数据包大小，按照各个第二子数据包的接收顺序，将所述目标第二子数据包和接收到的其它第二子数据包整合成完整的响应数据包。

这里，可以在按照各个第二子数据包的接收顺序，将目标第二子数据包和接收到的其它第二子数据包进行整合时，确定无法将整数个第二子数据包整合为与完整数据大小匹配的响应数据包，则对最后整合进该响应数据包的第二子数据包进行切分，以得到与完整数据大小匹配的响应数据包。

在具体实施中，可以判断目标第二子数据包和接收到的其它第二子数据包的大小之和是否小于完整数据包大小，如果小于，则继续接收第二子数据包；如果大于，也就是无法将整数个第二子数据包整合为与完整数据大小匹配的响应数据包时，可以计算出目标第二子数据包和接收到的其它第二子数据包的大小之和与完整数据包大小的数据量差额，然后根据该数据量差额，对最后整合进该响应数据包的第二子数据包进行切分，得到一个子数据包，将得到的子数据包与目标第二子数据包、接收到的其它第二子数据包进行整合，得到与完整数据大小匹配的响应数据包。对最后整合进该响应数据包的第二子数据包进行切分的地方就是下一个完整数据包的头部协议数据段开始的地方。

通过重复上述过程，就可以得到多个完整的响应数据包。最后每个第二子数据包都会整合进一个完整的响应数据包，而不会出现剩余的情况。

如图3所示，为本公开实施例提供的第三种数据处理方法的流程图，本公开实施例提供的数据处理方法应用在电脑端远程联调手机端的场景中。其中，电脑端和手机端位于应用层，电脑端可以远程调用运行在手机端的SDK中的数据。电脑端与手机端确定多个请求数据包分别对应的第一接口调用信息之前需要建立通信连接。具体地，电脑端与手机端可以基于TPC协议建立套接字socket通信连接，基于socket通信连接电脑端和手机端可以进行数据传输。在电脑端与手机端发送数据包之前，电脑端与手机端通过socket通信连接可以确定添加到请求数据包中的头部协议，其中头部协议可以包括应用层头部协议和网络层头部协议。

在远程联调的场景中，电脑端与手机端建立socket通信连接之后，电脑端可以向手机端发送用于请求手机端中SDK的数据的请求数据包，手机端为电脑端提供SDK的数据的服务，因此，这里可以定义电脑端为客户端，手机端为服务端。

电脑端可以把关于调用手机端SDK数据的接口调用和功能模块等有关的字段信息转换成JSON数据交换格式的请求数据包，然后对JSON数据报进行组装，也就是添加应用层头部协议。应用层头部协议数据段中可以包括第一接口调用信息，第一接口调用信息中可以包括CallEnderID接口标识、HasretValue接口类型(即是否有返回值)和CallEnderType消息类型等。

其中，每个接口都添加有唯一的接口标识，电脑端和手机端可以根据接口标识准确定位到每个接口。例如电脑端请求手机端中接口A的数据，手机端收到请求数据包后会根据接口标识，确定出与该接口标识对应的接口A的数据。

接口类型指的是同步请求或异步请求的类型，同步请求时电脑端发送请求数据包后同步等待手机端返回的数据，异步请求时电脑端发送请求数据包后不需要阻塞等待手机端返回的数据。

在添加完应用层头部协议之后，还可以添加网络层头部协议，网络层头部协议数据段中包括完整请求数据包的大小，以及请求数据包的类型。

根据网络层头部协议数据段处理在数据发送过程中的粘包、拆包和组包的过程。具体地，当请求数据包超过了单线程通道单次发送的数据包大小时，在数据发送端可以主动将请求数据包进行拆分，即拆包过程。当数据接收端接收到被拆分的多个子数据包的时候，可以将子数据包组合成一个完整的数据包，即组包过程。在数据发送过程中，如果不止一个请求数据包被发送，数据接收端同时接到多个完整请求数据包的过程为粘包。

在增加网络层头部协议之后，判断待发送的请求数据包的大小是否超过了预设的单次发送的数据包大小的数值(这里可以设置4K)，如果超过，则将请求数据包拆分成小于或等于单次发送的数据包大小的子数据包，并将拆分后得到的子数据包存入缓存队列中；如果未超过，则将请求数据包直接存入到缓存队列中。针对存入缓存队列中的子数据包或者未超过单次发送的数据包大小的请求数据包，利用单线程通道模型和循环(Loop)机制进行二进制发送。

通过接口适配层和socket协议可以将拆分后的子数据包或者单次发送的数据包大小的请求数据包发送到手机端。

手机端的端口可以监听是否接收到子数据包，当服务端接收到子数据包之后，可以将子数据包加入到服务端的缓存队列中，并判断对接收到的子数据包是否已读取头部协议数据，如果没有，则通过对请求数据包中的头部协议数据段进行解析，对解析出来的携带有头部协议数据段对应的子数据包设置标志位。接下来判断携带有头部协议数据段对应的子数据包和接收到的其他子数据包的大小之后是否小于完整请求数据包大小，如果小于，则说明当前未完成组包，继续从缓存队列中接收子数据包；如果大于，可以计算携带有头部协议数据段对应的子数据包的大小之和与完整请求数据包大小的数据量差额，然后根据该数据量差额，对最后整合进完整请求数据包的子数据包进行拆分，得到真实的数据包。将真实的数据包与携带有头部协议数据段对应的子数据包、接收到的其它子数据包进行整合，得到完整请求数据包。

然后完整请求数据包回调给手机端的应用层，应用层调取与完整请求数据包对应的响应数据包，手机端将响应数据包发送给电脑端。手机端在向电脑端发送响应数据包的时候，同样需要对响应数据包的大小进行判断，当响应数据包的大小超过了预设的单次发送的数据包大小的数值时，则对响应数据包进行拆分，得到完整响应数据包对应的多个子数据包，并依此发送至电脑端。电脑端接收完整响应数据包对应的多个子数据包，并将多个子数据包整合成完整的响应数据包。这里，电脑端整合响应数据包的多个子数据包的过程与手机端整合请求数据包的多个子数据包的过程类似，这里不再赘述。

当电脑端发送多个请求数据包时，电脑端和手机端重复执行上述过程，就可以调取到多个SDK对应的响应数据包，从而完成远程联调。

本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。

基于同一发明构思，本公开实施例中还提供了与数据处理方法对应的数据处理装置，由于本公开实施例中的装置解决问题的原理与本公开实施例上述数据处理方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

参照图4所示，为本公开实施例提供的一种数据处理装置的架构示意图，所述装置包括：获取模块401、第一确定模块402、第二确定模块403、发送模块404；其中，

获取模块401，用于获取多个请求数据包；

第一确定模块402，用于通过与目标终端进行通信协商确定所述多个请求数据包分别对应的第一接口调用信息，并将所述第一接口调用信息写入所述请求数据包的头部协议数据段中；

第二确定模块403，用于基于所述第一接口调用信息，以及预先设置的不同接口之间的上下文关系，确定所述多个请求数据包的发送顺序；

发送模块404，用于基于所述发送顺序，利用单线程通道将携带有所述第一接口调用信息的所述多个请求数据包依次发送至目标终端。

一种可能的实施方式中，发送模块404，具体用于：

基于单次发送的数据包大小，对所述请求数据包进行拆分处理，得到多个第一子数据包；所述多个第一子数据包中包括至少一个数据量与所述单次发送的数据包大小相等的目标第一子数据包；

若所述多个第一子数据包中，存在数据量小于所述单次发送的数据包大小的第一子数据包，则确定所述单次发送的数据包大小与存在的该第一子数据包的大小之间的数据量差额；

按照所述数据量差额，从与所述请求数据包相邻的下一个请求数据包中拆分出子数据包，与所述数据量小于所述单次发送的数据包大小的第一子数据包进行整合，得到数据量与所述单次发送的数据包大小相等的目标第一子数据包；

基于所述多个请求数据包的发送顺序，利用单线程通道将多个目标第一子数据包依次发送至目标终端。

一种可能的实施方式中，发送模块404，具体用于：

基于所述多个请求数据包的发送顺序以及各个请求数据包中第一子数据包的排列顺序，将所述多个目标第一子数据包加入到缓存队列；

从所述缓存队列中依次提取各个目标第一子数据包，并利用单线程通道将提取的目标第一子数据包依次发送至目标终端。

一种可能的实施方式中，发送模块404，具体用于：

针对每个请求数据包，判断所述请求数据包的目标第一子数据包是否全部加入缓存队列；

若所述请求数据包的目标第一子数据包全部加入缓存队列时，则基于所述多个请求数据包的发送顺序以及各个请求数据包中第一子数据包的排列顺序，将下一个请求数据包的多个目标第一子数据包加入到缓存队列。

一种可能的实施方式中，所述装置还包括：

接收模块，用于依次接收所述目标终端利用单线程通道发送的第二子数据包；

第三确定模块，用于确定所述第二子数据包中携带有头部协议数据段的目标第二子数据包；

第一解析模块，用于从所述目标第二子数据包携带的头部协议数据段中解析得到所述目标第二子数据包对应的完整数据包大小；

整合模块，用于基于所述完整数据包大小，按照各个第二子数据包的接收顺序，将所述目标第二子数据包和接收到的其它第二子数据包整合成完整的响应数据包。

一种可能的实施方式中，所述装置还包括：

第二解析模块，用于从所述目标第二子数据包携带的头部协议数据段中解析得到所述目标第二子数据包的第二接口调用信息；

查找模块，用于基于所述第二接口调用信息，查找本地存储的与该第二接口调用信息对应的头部协议数据段的目标信息格式；

比对模块，用于将所述目标信息格式与所述目标第二子数据包携带的头部协议数据段的信息格式进行比对；

第四确定模块，用于在比对一致的情况下，确定所述目标第二子数据包的合法性校验通过。

一种可能的实施方式中，整合模块，具体用于：

在按照各个第二子数据包的接收顺序，将所述目标第二子数据包和接收到的其它第二子数据包进行整合时，确定无法将整数个第二子数据包整合为与所述完整数据大小匹配的响应数据包，则对最后整合进该响应数据包的第二子数据包进行切分，以得到与所述完整数据大小匹配的响应数据包。

一种可能的实施方式中，所述装置还包括：

建立模块，用于基于传输控制协议TCP，与所述手机端之间建立套接字socket通信连接，以便所述电脑端与所述手机端之间基于所述socket通信连接进行数据传输。

关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明，这里不再详述。

基于同一技术构思，本公开实施例还提供了一种计算机设备。参照图5所示，为本公开实施例提供的计算机设备500的结构示意图，包括处理器501、存储器502、和总线503。其中，存储器502用于存储执行指令，包括内存5021和外部存储器5022；这里的内存5021也称内存储器，用于暂时存放处理器501中的运算数据，以及与硬盘等外部存储器5022交换的数据，处理器501通过内存5021与外部存储器5022进行数据交换，当计算机设备500运行时，处理器501与存储器502之间通过总线503通信，使得处理器501在执行以下指令：

获取多个请求数据包；

通过与目标终端进行通信协商确定所述多个请求数据包分别对应的第一接口调用信息，并将所述第一接口调用信息写入所述请求数据包的头部协议数据段中；

基于所述第一接口调用信息，以及预先设置的不同接口之间的上下文关系，确定所述多个请求数据包的发送顺序；

基于所述发送顺序，利用单线程通道将携带有所述第一接口调用信息的所述多个请求数据包依次发送至目标终端。

本公开实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述方法实施例中所述的数据处理方法的步骤。其中，该存储介质可以是易失性或非易失的计算机可读取存储介质。

本公开实施例还提供一种计算机程序产品，该计算机产品承载有程序代码，所述程序代码包括的指令可用于执行上述方法实施例中所述的数据处理方法的步骤，具体可参见上述方法实施例，在此不再赘述。

其中，上述计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序产品具体体现为计算机存储介质，在另一个可选实施例中，计算机程序产品具体体现为软件产品，例如软件开发包(Software Development Kit，SDK)等等。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统和装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。在本公开所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本公开各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上所述实施例，仅为本公开的具体实施方式，用以说明本公开的技术方案，而非对其限制，本公开的保护范围并不局限于此，尽管参照前述实施例对本公开进行了详细的说明，本领域的普通技术人员应当理解：任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化，或者对其中部分技术特征进行等同替换；而这些修改、变化或者替换，并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。

Claims (11)

1.一种数据处理方法，其特征在于，包括：

获取多个请求数据包；

通过与目标终端进行通信协商确定所述多个请求数据包分别对应的第一接口调用信息，并将所述第一接口调用信息写入所述请求数据包的头部协议数据段中；

基于所述第一接口调用信息，以及预先设置的不同接口之间的上下文关系，确定所述多个请求数据包的发送顺序；

基于所述发送顺序，利用单线程通道将携带有所述第一接口调用信息的所述多个请求数据包依次发送至目标终端。

2.根据权利要求1所述的方法，其特征在于，所述基于所述多个请求数据包的发送顺序，利用单线程通道将所述多个请求数据包依次发送至目标终端，包括：

基于单次发送的数据包大小，对所述请求数据包进行拆分处理，得到多个第一子数据包；所述多个第一子数据包中包括至少一个数据量与所述单次发送的数据包大小相等的目标第一子数据包；

若所述多个第一子数据包中，存在数据量小于所述单次发送的数据包大小的第一子数据包，则确定所述单次发送的数据包大小与存在的该第一子数据包的大小之间的数据量差额；

按照所述数据量差额，从与所述请求数据包相邻的下一个请求数据包中拆分出子数据包，与所述数据量小于所述单次发送的数据包大小的第一子数据包进行整合，得到数据量与所述单次发送的数据包大小相等的目标第一子数据包；

基于所述多个请求数据包的发送顺序，利用单线程通道将多个目标第一子数据包依次发送至目标终端。

3.根据权利要求2所述的方法，其特征在于，基于所述多个请求数据包的发送顺序，利用单线程通道将多个目标第一子数据包依次发送至目标终端，包括：

基于所述多个请求数据包的发送顺序以及各个请求数据包中第一子数据包的排列顺序，将所述多个目标第一子数据包加入到缓存队列；

从所述缓存队列中依次提取各个目标第一子数据包，并利用单线程通道将提取的目标第一子数据包依次发送至目标终端。

4.根据权利要求3所述的方法，其特征在于，所述将所述多个目标第一子数据包加入到缓存队列，包括：

针对每个请求数据包，判断所述请求数据包的目标第一子数据包是否全部加入缓存队列；

若所述请求数据包的目标第一子数据包全部加入缓存队列时，则基于所述多个请求数据包的发送顺序以及各个请求数据包中第一子数据包的排列顺序，将下一个请求数据包的多个目标第一子数据包加入到缓存队列。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

依次接收所述目标终端利用单线程通道发送的第二子数据包；

确定所述第二子数据包中携带有头部协议数据段的目标第二子数据包；

从所述目标第二子数据包携带的头部协议数据段中解析得到所述目标第二子数据包对应的完整数据包大小；

基于所述完整数据包大小，按照各个第二子数据包的接收顺序，将所述目标第二子数据包和接收到的其它第二子数据包整合成完整的响应数据包。

6.根据权利要求5所述的方法，其特征在于，确定所述第二子数据包中携带有头部协议数据段的目标第二子数据包之后，从所述目标第二子数据包携带的头部协议数据段中解析得到所述目标第二子数据包对应的完整数据包大小之前，所述方法还包括：

从所述目标第二子数据包携带的头部协议数据段中解析得到所述目标第二子数据包的第二接口调用信息；

基于所述第二接口调用信息，查找本地存储的与该第二接口调用信息对应的头部协议数据段的目标信息格式；

将所述目标信息格式与所述目标第二子数据包携带的头部协议数据段的信息格式进行比对；

在比对一致的情况下，确定所述目标第二子数据包的合法性校验通过。

7.根据权利要求5所述的方法，其特征在于，基于所述完整数据包大小，按照各个第二子数据包的接收顺序，将所述目标第二子数据包和接收到的其它第二子数据包整合成完整的响应数据包，包括：

在按照各个第二子数据包的接收顺序，将所述目标第二子数据包和接收到的其它第二子数据包进行整合时，确定无法将整数个第二子数据包整合为与所述完整数据大小匹配的响应数据包，则对最后整合进该响应数据包的第二子数据包进行切分，以得到与所述完整数据大小匹配的响应数据包。

8.根据权利要求1所述的方法，其特征在于，所述方法应用于远程服务联调中，所述方法的执行主体为电脑端，所述目标终端为手机端；

所述电脑端与手机端进行通信协商确定所述多个请求数据包分别对应的第一接口调用信息之前，包括：

基于传输控制协议TCP，与所述手机端之间建立套接字socket通信连接，以便所述电脑端与所述手机端之间基于所述socket通信连接进行数据传输。

9.一种数据处理装置，其特征在于，包括：

获取模块，用于获取多个请求数据包；

第一确定模块，用于通过与目标终端进行通信协商确定所述多个请求数据包分别对应的第一接口调用信息，并将所述第一接口调用信息写入所述请求数据包的头部协议数据段中；

第二确定模块，用于基于所述第一接口调用信息，以及预先设置的不同接口之间的上下文关系，确定所述多个请求数据包的发送顺序；

发送模块，用于基于所述发送顺序，利用单线程通道将携带有所述第一接口调用信息的所述多个请求数据包依次发送至目标终端。

10.一种计算机设备，其特征在于，包括：处理器、存储器和总线，所述存储器存储有所述处理器可执行的机器可读指令，当计算机设备运行时，所述处理器与所述存储器之间通过总线通信，所述机器可读指令被所述处理器执行时执行如权利要求1至8任一项所述的数据处理方法的步骤。

11.一种计算机可读存储介质，其特征在于，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行如权利要求1至8任一项所述的数据处理方法的步骤。

Images