CN114337938A - 一种数据传输方法、数据重传方法、装置和相关设备 - Google Patents

Abstract

本发明提供了一种数据传输方法、数据重传方法、装置和相关设备，包括：接收发送端传输的微数据包；判断微数据包是否被成功接收，并判断微数据包是否在第一上传窗口内；若微数据包被成功接收，且微数据包在第一上传窗口内，将微数据包确定为允许上传的微数据包；若微数据包未被成功接收，生成第一错误指令，并将第一错误指令返回至发送端，以使发送端重新传输微数据包。由于第一上传窗口限定的允许上传的微数据包是多个连续的微数据包，因此，即便在第一上传窗口内的一个微数据包未被成功接收，也不会影响该第一上传窗口内其他微数据包的上传，从而可以减少数据重传过程中带宽的损失，提高带宽的利用率。

Description

一种数据传输方法、数据重传方法、装置和相关设备

技术领域

本发明实施例涉及计算机技术领域，具体涉及一种数据传输方法、数据重传方法、装置和相关设备。

背景技术

片上网络(Network On Chip，简称NOC)是片上系统(System On Chip，简称SOC)的一种通信方式。由于采用片上网络进行互连通信的片上系统的性能显著优于采用总线进行互连通信的片上系统的性能，因此，片上网络已经成为目前应用最广泛的一种实现多核处理器互连通信的结构。但是，在当前的片上网络内，实现数据重传的方式会损失带宽，导致带宽的利用率较低。

发明内容

有鉴于此，本发明实施例提供一种数据传输方法、数据重传方法、装置和相关设备，以减少数据重传过程中带宽的损失，提高带宽的利用率。

为解决上述问题，本发明实施例提供如下技术方案：

本发明第一方面提供了一种数据传输方法，应用于接收端，包括：

接收发送端传输的微数据包；

判断所述微数据包是否被成功接收，并判断所述微数据包是否在第一上传窗口内；

若所述微数据包被成功接收，且所述微数据包在第一上传窗口内，将所述微数据包确定为允许上传的微数据包；所述第一上传窗口用于限定允许上传的多个连续的微数据包的范围；

若所述微数据包未被成功接收，生成第一错误指令，并将所述第一错误指令返回至所述发送端；所述第一错误指令用于指示所述微数据包未被成功接收，以使所述发送端重新传输所述微数据包。

本发明第二方面提供了一种数据重传方法，应用于发送端，包括：

获取接收端传输的第一错误指令；所述第一错误指令用于指示对应的一个微数据包未被成功接收；

根据所述第一错误指令，确定重新传输的微数据包；所述重新传输的微数据包为所述第一错误指令指示未被成功接收的一个微数据包；

将所述重新传输的微数据包传输至所述接收端。

本发明第三方面提供了一种数据传输装置，应用于接收端，包括：

第一传输模块，用于接收发送端传输的微数据包；

判断模块，用于判断所述微数据包是否被成功接收，并判断所述微数据包是否在第一上传窗口内；

上传控制模块，用于在所述微数据包被成功接收，且所述微数据包在第一上传窗口内时，将所述微数据包确定为允许上传的微数据包；所述第一上传窗口用于限定允许上传的多个连续的微数据包的范围；在所述微数据包未被成功接收时，生成第一错误指令，并将所述第一错误指令发送至所述第一传输模块；

所述第一传输模块还用于将所述第一错误指令返回至所述发送端；所述第一错误指令用于指示所述微数据包未被成功接收，以使所述发送端重新传输所述微数据包。

本发明第四方面提供了一种数据重传装置，应用于发送端，包括：

第二传输模块，用于获取接收端传输的第一错误指令；所述第一错误指令用于指示对应的一个微数据包未被成功接收；

重传控制模块，用于根据所述第一错误指令，确定重新传输的微数据包；所述重新传输的微数据包为所述第一错误指令指示未被成功接收的一个微数据包；

所述第二传输模块还用于将所述重新传输的微数据包传输至所述接收端。

本发明第五方面提供了一种计算机设备，包括：

存储器，存储至少一组指令；

处理器，执行所述至少一组指令执行如上任一项所述的数据传输方法，或者，如上任一项所述的数据重传方法。

本发明第六方面提供了一种可读存储介质，所述可读存储介质存储至少一组指令，所述至少一组指令用于使处理器执行如上任一项所述的数据传输方法，或者，如上任一项所述的数据重传方法。

本发明实施例提供的数据传输方法、数据重传方法、装置和相关设备，接收发送端传输的微数据包之后，判断该微数据包是否被成功接收，并判断该微数据包是否在第一上传窗口内。由于第一上传窗口限定了允许上传的多个连续的微数据包的范围，因此，若该微数据包被成功接收，且该微数据包在第一上传窗口限定的微数据包的范围内，即，该微数据包为第一上传窗口限定的多个连续的微数据包中的任意一个，即可将该微数据包确定为允许上传的微数据包。

若该微数据包未被成功接收，则生成第一错误指令，并将第一错误指令返回至发送端，使发送端重新传输该微数据包。接收到发送端重新传输的该微数据包之后，重复判断微数据包是否被成功接收、判断微数据包是否在第一上传窗口内以及之后的步骤，直到将该微数据包确定为允许上传的微数据包为止。

可以看出，由于第一上传窗口限定的允许上传的微数据包是多个连续的微数据包，因此，即便在第一上传窗口内的一个微数据包未被成功接收，也不会影响该第一上传窗口内其他微数据包的上传，基于此，只需将未被成功接收的一个微数据包重新传输即可，不需要再重新传输未被成功接收的微数据包之后被成功接收的微数据包，从而可以减少数据重传过程中带宽的损失，提高带宽的利用率。

附图说明

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

图1示例性的示出了一种发送窗口和接收窗口的窗口滑动协议示意图；

图2示例性的示出了一种微数据包顺序重传的流程示意图；

图3示例性的示出了一种数据传输方法的流程图；

图4示例性的示出了另一种数据传输方法的流程图；

图5示例性的示出了一种微数据包非顺序重传的流程示意图；

图6示例性的示出了一种第一上传窗口随第二上传窗口更新而更新的示意图；

图7示例性的示出了一种数据重传方法的流程图；

图8示例性的示出了一种数据传输装置的结构示意图；

图9示例性的示出了一种数据重传装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在当前的片上网络数据传输机制中，普遍采用了定长包传输控制法，即，将片上网络的网络层流转的数据包，切分成特定长度的微数据包，并将该微数据包作为传输控制单元在数据链路层进行传输。当出现传输错误导致微数据包未被成功接收时，亦以该微数据包为单位进行重新传输。

在片上网络中，微数据包的传输采用的是滑动窗口协议。在任意时刻，发送端都会维持一个连续的允许发送的微数据包的序列号集合，称为发送窗口。同时，接收端也会维持一个连续的允许接收的微数据包的序列号集合，称为接收窗口。发送窗口内的序列号为已经被发送但尚未确认是否被成功接收的微数据包的序列号，或者是可以被发送但尚未发送的微数据包的序列号。接收窗口内的序列号为允许接收或上传的微数据包的序列号。

其中，发送窗口和接收窗口的窗口尺寸可以不同，即，发送窗口和接收窗口的序列号集合中序列号的个数可以不同。一般情况下，接收窗口的窗口尺寸为1，即，在任意时刻接收窗口的序列号集合仅包含一个序列号，接收端每次仅将接收窗口内的一个序列号对应的微数据包上传至网络层，以实现微数据包的顺序上传，保证传输的可靠性。

图1示例性的示出了一种发送窗口和接收窗口的窗口滑动协议示意图。其中，图1仅以发送窗口的窗口尺寸为2、接收窗口的窗口尺寸为1为例进行说明，假设发送端要发送序列号为0、1、2、3、4、5、6、7的微数据包，在t0时刻，接收窗口的序列号为0，在t1时刻，发送窗口和接收窗口的序列号都为0，发送端向接收端发送序列号为0的微数据包，在t2时刻，发送窗口的序列号为0和1，接收窗口的序列号仍为0，发送端向接收端发送序列号为1的微数据包，在t3时刻，发送窗口的序列号为0和1，接收窗口的序列号为1，接收窗口接收序列号为0的微数据包，在t4时刻，发送窗口和接收窗口的序列号都为1，接收端已成功接收序列号为0的微数据包，在t5时刻，发送窗口的序列号为1和2，接收窗口的序列号为1，发送端向接收端发送序列号为2的微数据包，在t6时刻，发送窗口的序列号为1和2，接收窗口的序列号为2，接收窗口接收序列号为1的微数据包，在t7时刻，发送窗口和接收窗口的序列号都为2，接收端已成功接收序列号为1的微数据包。其他微数据包传输过程中的窗口滑动方式以此类推，在此不再赘述。

图1所示的窗口滑动协议虽然可以保证数据的可靠传输，但是，其采用的是基于后退N的(go-back-n)的窗口协议完成的重传控制。发送端在发送完一个微数据包后，不会停下来等待确认指令(Acknowledgment，Ack)，而是连续发送若干个微数据包，即使在连续发送过程中收到了接收端发来的确认指令也会继续发送。但是，若发送端接收到指示某一微数据包因传输错误而未被成功接收的错误指令(Acknowledgment，Nak)，则发送端会自出错的微数据包开始重新发送。

图2示例性的示出了一种微数据包顺序重传的流程示意图，如图2所示，当序列号为2的微数据包传输出错后，虽然其之后传输的序列号分别为3、4、5、6的微数据包正确传输即被成功接收，但是，接收端在未接收到正确的2号微数据包之前，会丢弃或删除后续的所有微数据包，即，丢弃或删除被成功接收的序列号分别为3、4、5、6的微数据包，这就造成了部分带宽的浪费，导致了带宽损失，降低了带宽的利用率。

基于此，本发明实施例提供了一种数据传输方案，在接收端设置第一上传窗口，并通过第一上传窗口限定允许上传的多个连续的微数据包的范围，使得在上述范围内的任一微数据包都可以上传，即便第一上传窗口内的一个微数据包未被成功接收，也不会影响第一上传窗口内的其他微数据包的上传，从而使得发送端只需将未被成功接收的微数据包重新传输即可，未被成功接收的微数据包之后被成功接收的微数据包不需要再重新传输，进而可以减少数据重传过程中带宽的损失，提高带宽的利用率。

作为本发明实施例公开内容的一种可选实现，本发明实施例提供了一种数据传输方法，应用于接收端，具体应用于接收端设备。该接收端设备可以是芯片等。并且，芯片为应用片上系统的芯片。此外，芯片可以是封装后的芯片，也可以是未封装的裸片(Die)。图3示例性的示出了一种数据传输方法的流程图，如图3所示，该数据传输方法包括：

S301：接收发送端传输的微数据包；

本发明实施例中，在发送端和接收端进行数据交互时，发送端的数据链路层获取片上网络的网络层流转的数据包，并将数据包切分成特定长度的微数据包，然后将该微数据包作为传输控制单元在发送端和接收端的数据链路层进行传输。其中，网络层流转的数据包可以是来自发送模块的数据包，该发送模块可以是发送端设备的事务层(TransactionLayer Protocol，简称TLP)，也可以是发送端设备的片上系统的各个功能模块如处理器核等。

需要说明的是，发送端发送的微数据包可以是首次传输的微数据包，也可以是重新传输的微数据包。其中，重新传输的微数据包可以是根据错误指令重新传输的微数据包，也可以是根据超时重传指令重新传输的微数据包。

S302：判断微数据包是否被成功接收，并判断微数据包是否在第一上传窗口内；

图4示例性的示出了另一种数据传输方法的流程图，在步骤S401中，发送端的数据链路层会将微数据包缓存到发送端的重发缓冲区(Replay Buffer)中，待需要发送微数据包时，从重发缓冲区中获取微数据包，解析微数据包的类型，若该微数据包为需要发送至接收端的微数据包，则在步骤S402中，在微数据包中拼接控制信息如拼接序列号(SequenceNumber)等，并在微数据包中增加错误校验码(Cyclic Redundancy Check，简称CRC)，然后在步骤S403中，根据发送控制时序，将微数据包转换成物理编码子层(PCS)允许的接口类型，并下传给物理编码子层，以通过物理编码子层发送至接收端。

接收端的数据链路层通过物理编码子层接收发送端发送的微数据包，之后在步骤S404中，对微数据包进行检验，判断微数据包是否被成功接收，并判断微数据包是否在第一上传窗口内。

其中，判断微数据包是否被成功接收包括：判断微数据包中的校验码与重新生成的校验码是否相同，若相同，说明微数据包传输正确，微数据包被成功接收；若不同，说明微数据包传输错误，微数据包未被成功接收。

判断微数据包是否在第一上传窗口内包括：判断微数据包是否是第一上传窗口限定的允许上传的多个连续的微数据包中的任意一个，若是，说明微数据包在第一上传窗口内，若不是，说明微数据包不在第一上传窗口内。

S303：若微数据包被成功接收，且微数据包在第一上传窗口内，将微数据包确定为允许上传的微数据包；第一上传窗口用于限定允许上传的多个连续的微数据包的范围；

如图4所示，若微数据包被成功接收，且微数据包在第一上传窗口内，在步骤S405中，将微数据包确定为允许上传的微数据包，并在步骤S406中，向发送端返回确认指令Ack，通知发送端其已成功接收到微数据包。发送端在接收到确认指令Ack之后，在步骤S407中，将重发缓冲区中对应的微数据包删除，以释放缓存空间。

S304：若微数据包未被成功接收，生成第一错误指令，并将第一错误指令返回至发送端；第一错误指令用于指示微数据包未被成功接收，以使发送端重新传输微数据包；

如图4所示，若微数据包未被成功接收，生成第一错误指令Nak1，并在步骤S408中，将第一错误指令Nak1返回至发送端；第一错误指令Nak1用于指示微数据包传输错误，以使发送端重新传输微数据包。

在步骤S409中，发送端重新传输该微数据包，之后发送端跳出重传，继续正常数据的发送。之后，在步骤S410中，对重新传输的微数据包进行检验，判断重新传输的微数据包是否被成功接收，并判断重新传输的微数据包是否在第一上传窗口内。若重新传输的微数据包中的校验码与重新生成的校验码不同，说明重新传输的微数据包传输错误，重新传输的微数据包未被成功接收，返回步骤S408，将第一错误指令Nak1返回至发送端，以使发送端重新传输微数据包，直到重新传输的微数据包被成功接收为止。

若重新传输的微数据包中的校验码与重新生成的校验码相同，说明重新传输的微数据包传输正确，重新传输的微数据包被成功接收。之后在步骤S411中，将重新传输的微数据包确定为允许上传的微数据包，并按照微数据包的允许上传顺序将第一上传窗口更新为下一第一上传窗口。并在步骤S412中，向发送端返回确认指令Ack，通知发送端其已成功接收到微数据包，以使发送端将重发缓冲区中对应的微数据包删除。

本发明一些实施例中，若微数据包不在第一上传窗口内，无论微数据包是否被成功接收，都会丢弃或删除该微数据包，生成第二错误指令Nak2，并在步骤S413中，将第二错误指令Nak2返回至发送端；第二错误指令用于指示微数据包上传错误，以使发送端重新传输该微数据包。当然，本发明并不仅限于此，在另一些实施例中，还可以通过第二错误指令Nak2使发送端重新传输该微数据包及其之后的微数据包。即，在步骤S414中，发送端重新传输该微数据包或重新传输该微数据包及其之后的微数据包。

当然，在另一些实施例中，若微数据包不在第一上传窗口内，但该微数据包被成功接收，还可以缓存该微数据包，待第一上传窗口更新之后，再判断该微数据包是否在更新后的第一上传窗口内，若是，将该微数据包确定为允许上传的微数据包，若不在，继续缓存该微数据包。

图5示例性的示出了一种微数据包非顺序重传的流程示意图，如图5所示，当序列号为2的微数据包传输出错后，正确传输的序列号分别为3、4、5、6的微数据包并不会被丢弃或删除，而是继续上传，发送端仅重新传输错误的序列号为2的微数据包。

并且，发送端在每发送完一个微数据包后都会设置超时定时器。只要在设置的超时时间内未接收到该微数据包的确认指令，发送端就要重新传输该微数据包。如，当发送端发送了N个微数据包后，若发现第N个微数据包的前一个微数据包，如序列号为7的微数据包，在超时定时器超时后仍未接收到其确认指令，则该微数据包被判为出错或丢失。

本发明一些实施例中，如图5所示，发送端仅重新传输该出错的序列号为7的微数据包。而图2所示的重传方式中，发送端会重新传输该出错的序列号为3的微数据包及其之后的未出错的微数据包。

可以看出，在相同的时间段内，同样发生两次重传的情况下，图5所示的非顺序重传的方式可以多上传10个微数据包。当然，图5和图2中仅以一种具体情况为例进行说明，并不仅限于此，可以知道的是，传输链路的延迟越大，多上传的微数据包的个数越多。

需要说明的是，由于微数据包内的序列号与微数据包是一一对应的，因此，接收端在接收到微数据包后，会根据微数据包中的序列号，区分不同的微数据包。当然，微数据包必须包含精确的序列号，不能通过某种特定校验码方式隐式携带序列号，否则，接收端不能解析得到精确的序列号，不能根据序列号对微数据包进行区分。

同样，本发明一些实施例中，是根据微数据包的序列号，判断微数据包是否在第一上传窗口内的。即，判断微数据包是否在第一上传窗口内包括：判断微数据包的序列号是否在第一上传窗口限定的允许上传的微数据包的序列号范围内，或者说，判断微数据包的序列号是否是第一上传窗口限定的允许上传的多个连续的微数据包中任一微数据包的序列号。

但是，本发明并不仅限于此，在另一些实施例中，还可以根据微数据包的其他标识，区分微数据包以及判断微数据包是否在第一上传窗口内，在此不再赘述。

还需要说明的是，本发明一些实施例中，微数据包被确定为允许上传的微数据包之后，接收端的数据链路层会对微数据包进行冗余信息剥离等操作之后，如剥离错误检验码等信息，按照微数据包被确定为允许上传的微数据包的顺序，将微数据包上传至片上网络的网络层，以通过网路层将微数据包传输至接收模块，该接收模块可以为接收端设备的事务层，也可以是接收端设备的片上系统的各个功能模块如处理器核等。当然，接收端的数据链路层也可以通过自测试检测逻辑对微数据包进行检测之后，再上传至片上网络的网络层，在此不再赘述。

如图5所示，本发明一些实施例中，会按照0、1、3、4、5、6、2、8、9、10、11、12、13、14、7、15、16、17的序列号顺序将对应的微数据包上传。虽然微数据包的上传顺序与预期的微数据包上传顺序不同，预期的上传顺序为0、1、2、3、4、5、6、7、8、9、10、11、12、13、14、15、16、17的序列号顺序，但是，对于一些对数据接收无顺序要求的应用场景而言，可以减少数据重传过程中带宽的损失，提高带宽的利用率，降低顺序重传导致的接收模块接收数据的延迟。

当然，本发明并不仅限于此，在另一些实施例中，将重新传输的微数据包确定为允许上传的微数据包之后，还包括：对重新传输的微数据包以及多个连续的微数据包中的其他微数据包进行排序，以使重新传输的微数据包以及其他微数据包仍按照微数据包的期望上传顺序上传。

如，将0、1、3、4、5、6、2、8、9、10、11、12、13、14、7、15、16、17序列号顺序对应的微数据包的上传顺序调整为0、1、2、3、4、5、6、7、8、9、10、11、12、13、14、15、16、17的序列号顺序。虽然接收模块仍会延迟接收数据，但是，同样减少了数据重传过程中有效带宽的损失，提高了带宽的利用率。

需要说明的是，本发明实施例中仅以期望上传是0、1、3、4、5、6、2、8、9、10、11、12、13、14、7、15、16、17为例进行说明，但是，本发明并不仅限于此，实际期望上传顺序为发送端从网络层接收微数据包的顺序。

还需要说明的是，序列号是根据微数据包的存储地址，如根据微数据包在重发缓冲区的存储地址，生成的与微数据包唯一对应的序列号。其中，序列号可以为8位的序列号，也可以为12位的序列号。并且，按照微数据包的发送顺序，序列号是依次增大的。

本发明实施例中，由于第一上传窗口限定了允许上传的多个连续的微数据包的范围，即第一上传窗口限定的允许上传的微数据包范围包括多个连续的微数据包，也即第一上传窗口的窗口尺寸大于1，因此，即便该微数据包范围内的一个微数据包未被成功接收，也不会影响该微数据包范围内的其他微数据包的上传。基于此，只需将未被成功接收的微数据包重新传输即可，未被成功接收的微数据包之后被成功接收的微数据包不需要再重新传输，从而可以减少数据重传过程中有效带宽的损失，提高带宽的利用率。

在上述任一实施例的基础上，本发明一些实施例中，数据传输方法还包括：

若微数据包未被成功接收，且微数据包在第一上传窗口内，保持第一上传窗口不变；

若重新传输的微数据包被成功接收，且重新传输的微数据包在第一上传窗口内，将重新传输的微数据包确定为允许上传的微数据包，并按照微数据包的期望上传顺序将第一上传窗口更新为下一第一上传窗口。

假设第一上传窗口限定的微数据包的序列号范围为{1,2,3,4}，若序列号为1的微数据包未被成功接收，则保持第一上传窗口不变，即保持第一上传窗口的序列号范围为{1,2,3,4}。在接收端向发送端返回指示序列号为1的微数据包错误的第一错误指令Nak1以及发送端重新传输序列号为1的微数据包的过程中，序列号为2、3、4的微数据包仍会被确定为允许上传的微数据包，并依次上传，但是，除1、2、3、4之外的其他序列号的微数据包不允许上传，会被丢弃或删除。直到重新传输的序列号为1的微数据包被成功接收之后，将重新传输的微数据包确定为允许上传的微数据包，按照微数据包的期望上传顺序将第一上传窗口更新为下一第一上传窗口。假设微数据包的期望上传顺序为0、1、2、3、4、5、6、7、8…，更新后的第一上传窗口的微数据包的序列号范围为{5,6,7,8}。

需要说明的是，上述实施例中仅以第一上传窗口的窗口尺寸为4为例进行说明，本发明并不仅限于此，在另一些实施例中，第一上传窗口的窗口尺寸还可以为5、6、7、8等。本发明一些实施例中，第一上传窗口的窗口尺寸与第一个微数据包的重传延时对应，即，若序列号为1的微数据包未被成功接收，则在重新接收到序列号为1的微数据包的期间，第一上传窗口一直在上传微数据包，并没有空闲等待时间。

基于此，在第一上传窗口内的微数据包未被成功接收的情况下，保持第一上传窗口不变，使得仅在第一上传窗口限定的微数据包范围内打乱了微数据包的上传顺序。在将重新传输的微数据包确定为允许上传的微数据包之后，由于仍按照微数据包的期望上传顺序将第一上传窗口更新为下一第一上传窗口，因此，微数据包的整体上传顺序还是与微数据包的期望上传顺序大体一致的。对于一些对微数据包接收顺序无强制要求的应用场景而言，并不会影响数据的传输效果。对于一些对微数据包接收顺序有强制要求的应用场景而言，可以在接收到一个第一上传窗口内的多个微数据包之后，再对多个微数据包进行排序，也不会影响数据的传输效果。

本发明一些实施例中，在第一上传窗口内的微数据包接收的过程中，第一上传窗口也可以保持不变。如，在接收序列号为1、2、3、4的微数据包的过程中，第一上传窗口保持序列号范围为{1,2,3,4}不变，待序列号为1、2、3、4的微数据包全部被成功接收之后，第一上传窗口的序列号范围更新为{5,6,7,8}。

但是，本发明并不仅限于此，在另一些实施例中，第一上传窗口也可以随接收到的微数据包的情况变化而更新。如，假设第一上传窗口的初始序列号范围为{1,2,3,4}，序列号为1的微数据包被成功接收以后，第一上传窗口的序列号范围更新为{2,3,4,5}，序列号为2的微数据包被成功接收以后，第一上传窗口的序列号范围更新为{3,4,5,6}，以保证第一上传窗口限定范围内的微数据包按照期望顺序上传。

基于此，本发明一些实施例中，不仅包括第一上传窗口，还包括第二上传窗口。第二上传窗口用于限定允许上传的一个微数据包的范围，即第二上传窗口的窗口尺寸等于1，并且，第二上传窗口限定的允许上传的微数据包的范围在第一上传窗口限定的允许上传的微数据包的范围内。

在一个具体实例中，第二上传窗口限定的允许上传的微数据包为第一上传窗口限定的允许上传的多个连续的微数据包中的第一个微数据包。如，第一上传窗口的序列号范围为{1,2,3,4}，第二上传窗口的序列号范围为{1}，以通过第二上传窗口保证第一上传窗口范围内的微数据包按照期望顺序上传。当然，本发明并不仅限于此，在另一些实施例中，第二上传窗口限定的允许上传的微数据包为第一上传窗口限定的允许上传的多个连续的微数据包中的第二个微数据包或第三个微数据包等。

基于此，判断微数据包是否在第一上传窗口内包括：

判断微数据包是否在第二上传窗口内；

若微数据包在第二上传窗口内，则微数据包在第一上传窗口内；

若微数据包不在第二上传窗口内，判断微数据包是否在第一上传窗口除第二上传窗口之外的范围内，若微数据包在第一上传窗口除第二上传窗口之外的范围内，则微数据包在第一上传窗口内。

以第一上传窗口的序列号范围为{1,2,3,4}，第二上传窗口的序列号范围为{1}为例，若微数据包的序列号为1，则该微数据包在第二上传窗口内，由于第二上传窗口限定的允许上传的微数据包的范围在第一上传窗口限定的允许上传的微数据包的范围内，因此，该微数据包必然在第一上传窗口内，从而可以将该微数据包确定为允许上传的微数据包；若微数据包的序列号为2，则该微数据包不在第二上传窗口内，判断微数据包是否在第一上传窗口除第二上传窗口之外的范围{2,3,4}内，若在，说明该微数据包在第一上传窗口内，将微数据包确定为允许上传的微数据包。若微数据包的序列号为5，则该微数据包既不在第二上传窗口内，也不在第一上传窗口内，返回第二错误指令Nak2至发送端，使发送端重新传输该微数据包或者重新传输该微数据包以及之后的微数据包。

在上述实施例的基础上，本发明一些实施例中，数据传输方法还包括：

若微数据包被成功接收，且微数据包在第二上传窗口内，按照微数据包的期望上传顺序将第二上传窗口更新为下一第二上传窗口；

若微数据包未被成功接收，但微数据包在第二上传窗口内，保持第二上传窗口不变；

若重新传输的微数据包被成功接收，且微数据包在第二上传窗口内，将重新传输的微数据包确定为允许上传的微数据包，并按照微数据包的期望上传顺序将第二上传窗口更新为下一第二上传窗口。

也就是说，若微数据包被成功接收，且微数据包在第二上传窗口内，按照微数据包的期望上传顺序将第二上传窗口更新为下一第二上传窗口。如第二上传窗口按照微数据包的期望上传顺序1、2、3、4、5、6…更新，若第二上传窗口的序列号范围为{1}，更新后第二上传窗口的序列号范围为{2}。

若微数据包未被成功接收，但微数据包在第二上传窗口内，如微数据包的序列号为1，但该微数据包未被成功接收，则保持第二上传窗口的序列号范围为{1}不变，生成第一错误指令Nak1，并将第一错误指令Nak1返回至发送端，以使发送端重新传输该微数据包。若重新传输的序列号为1的微数据包被成功接收，将微数据包确定为允许上传的微数据包，并按照微数据包的期望上传顺序将第二上传窗口更新为下一第二上传窗口。

同样，本发明一些实施例中，可以根据序列号，判断微数据包是否在第二上传窗口内，即判断微数据包是否在第二上传窗口内包括：判断微数据包的序列号是否为第二上传窗口限定的允许上传的一个微数据包的序列号。当然，在另一些实施例中，也可以根据微数据包的其他标识，判断微数据包是否在第二上传窗口内，在此不再赘述。

本发明一些实施例中，按照微数据包的期望上传顺序将第二上传窗口更新为下一第二上传窗口之后，还包括：按照微数据包的期望上传顺序将第一上传窗口更新为下一第一上传窗口。

图6示例性的示出了一种第一上传窗口随第二上传窗口更新而更新的示意图，以第一上传窗口的序列号范围为{1,2,3,4}，第二上传窗口的序列号范围为{1}为例进行说明，序列号为1的微数据包确定为允许上传的微数据包之后，第二上传窗口的序列号范围按照微数据包的允许上传顺序后移更新为{2}，第一上传窗口的序列号范围按照微数据包的允许上传顺序后移更新为{2,3,4,5}；若序列号为1的微数据包出现错误，第一上传窗口保持序列号范围为{1,2,3,4}不变，待重新传输的序列号为1的微数据包被确定为允许上传的微数据包之后，若序列号为2、3、4的微数据包已经被确定为允许上传的微数据包，那么，按照微数据包的期望上传顺序第二上传窗口的序列号范围后移更新为{5}，第一上传窗口的序列号范围后移更新为{5,6,7,8}。也就是说，第一上传窗口的窗口尺寸保持不变，但下限序列号与第二上传窗口的序列号保持一致。

在上述实施例的基础上，本发明一些实施例中，若被成功接收的微数据包不在第二上传窗口内，但微数据包在第一上传窗口内，将该微数据包确定为允许上传的微数据包之前，还包括：

判断微数据包是否具有重复的微数据包；

若没有，将微数据包确定为允许上传的微数据包。

也就是说，若微数据包不在第二上传窗口内，但微数据包在第一上传窗口内，还需判断该微数据包是否为唯一的，即接收端是否具有与该微数据包重复的或相同的微数据包，若没有，将微数据包确定为允许上传的微数据包，若有，丢弃或删除该微数据包。本发明一些实施例中，可以将重复的微数据包确定为允许上传的微数据包，也可以丢弃或删除该微数据包以及重复的微数据包，并将第二错误指令Nak2返回至发送端，以使发送端重新传输该微数据包。

需要说明的是，若微数据包被成功接收，且微数据包在第一上传窗口内，则可以在该微数据包打上正确上传标志；若微数据包未被成功接收，则可以在该微数据包打上校验错误标志；若微数据包被成功接收，且微数据包不在第二上传窗口内，则可以在该微数据包打上待确认标志；若微数据包被成功接收，但微数据包不在第一上传窗口内，可以在微数据包打上上传错误标志，以对不同判定结果的微数据包进行区分处理。

本发明实施例中，通过第二上传窗口和第一上传窗口的有效配合和精确控制，不仅实现了微数据包的高效、精确重传，而且减少了数据重传过程中有效带宽的损失，提高了带宽的利用率。

作为本发明实施例公开内容的另一种可选实现，本发明实施例提供了一种数据重传方法，应用于发送端，具体应用于发送端设备。该发送端设备可以是芯片等。并且，芯片为应用片上系统的芯片。此外，芯片可以是封装后的芯片，也可以是未封装的裸片。图7示例性的示出了一种数据重传方法的流程图，如图7所示，该数据重传方法包括：

S701：获取接收端传输的第一错误指令；第一错误指令用于指示对应的一个微数据包未被成功接收；

S702：根据第一错误指令，确定重新传输的微数据包；重新传输的微数据包为第一错误指令指示未被成功接收的一个微数据包；

S703：将重新传输的微数据包传输至接收端。

参考图4，在发送端和接收端进行数据交互时，发送端的数据链路层获取片上网络的网络层流转的数据包，并将数据包切分成特定长度的微数据包，然后发送端的数据链路层会将微数据包缓存到发送端的重发缓冲区中，之后从重发缓冲区中获取微数据包，在微数据包中拼接控制信息如拼接序列号等，并在微数据包中增加错误校验码，然后根据发送控制时序，将微数据包转换成物理编码子层允许的接口类型，并下传给物理编码子层，以通过物理编码子层发送至接收端。当然，在另一些实施例中，也可以先在微数据包中拼接控制信息、增加错误校验码，再把微数据包缓存到重发缓冲区中，在此不再赘述。

接收端的数据链路层通过物理编码子层接收发送端发送的微数据包，之后对微数据包进行检验，判断微数据包是否被成功接收，并判断微数据包是否在第一上传窗口内。若微数据包被成功接收，且微数据包在第一上传窗口内，将微数据包确定为允许上传的微数据包，并向发送端返回确认指令Ack，通知发送端其已成功接收到微数据包。发送端在接收到确认指令Ack之后，将重发缓冲区中对应的微数据包删除，以释放缓存空间。

若微数据包未被成功接收，生成第一错误指令Nak1，并将第一错误指令Nak1返回至发送端；第一错误指令Nak1用于指示微数据包传输错误，以使发送端重新传输微数据包。发送端获取接收端传输的第一错误指令之后，根据第一错误指令，确定重新传输的微数据包，并将重新传输的微数据包传输至接收端。

由于重新传输的微数据包为第一错误指令指示未被成功接收的一个微数据包，而不是自未被成功接收的微数据包起重新顺序发送微数据包，因此，可以减少数据重传过程中带宽的损失，提高带宽的利用率。

在上述实施例的基础上，本发明一些实施例中，还包括：

获取接收端传输的第一错误指令；第一错误指令用于指示对应的一个微数据包未被成功接收；

根据第一错误指令，确定重新传输的微数据包；重新传输的微数据包为第一错误指令指示未被成功接收的一个微数据包；

将重新传输的微数据包传输至接收端。

本发明实施例中，发送端在每发送完一个微数据包后都会设置超时定时器。只要在设置的超时时间内未接收到该微数据包的确认指令，超时定时器就会生成超时重传指令，发送端在获取超时重传指令之后，根据超时重传指令，确定重新传输的微数据包，并将重新传输的微数据包发送至接收端。

由于重新传输的微数据包为超时重传指令指示的在预设时间内未接收到确认指令的一个微数据包，而不是自超时未确认的微数据包起重新顺序发送微数据包，因此，可以减少数据重传过程中带宽的损失，提高带宽的利用率。

在上述实施例的基础上，本发明一些实施例中，还包括：

获取接收端发送的第二错误指令；第二错误指令用于指示一微数据包上传错误；

根据第二错误指令，确定重新传输的微数据包；重新传输的微数据包为第二错误指令指示的上传错误的微数据包，或，重新传输的微数据包为第二错误指令指示的上传错误的微数据包及其之后发送的微数据包；

将重新传输的微数据包发送至接收端。

参考图4，若微数据包不在第一上传窗口内，无论微数据包是否被成功接收，都会丢弃或删除该微数据包，生成第二错误指令Nak2，并将第二错误指令Nak2返回至发送端；第二错误指令用于指示微数据包上传错误，以使发送端重新传输该微数据包。

发送端获取接收端发送的第二错误指令之后，根据第二错误指令，确定重新传输的微数据包，并将重新传输的微数据包发送至接收端。若第一上传窗口的更新延迟较小，为了提高带宽利用率，重新传输的微数据包可以为第二错误指令指示的上传错误的微数据包，但是，若第一上传窗口的更新延迟较大，为了避免遗漏微数据包，重新传输的微数据包可以为第二错误指令指示的上传错误的微数据包及其之后发送的微数据包。

当然，本发明实施例中，发送端还可以根据其他指令重新传输微数据包，但是，重新传输的微数据包可以仅为一个微数据包，而不是自指定的微数据包起重新顺序发送微数据包，以减少数据重传过程中带宽的损失，提高带宽的利用率。

作为本发明实施例公开内容的另一种可选实现，本发明实施例提供了一种数据传输装置，应用于接收端，具体应用于接收端设备。该接收端设备可以是芯片等。并且，芯片为应用片上系统的芯片。此外，芯片可以是封装后的芯片，也可以是未封装的裸片。图8示例性的示出了一种数据传输装置的结构示意图，如图8所示，该数据传输装置包括：

第一传输模块81，用于接收发送端传输的微数据包；

判断模块82，用于判断微数据包是否被成功接收，并判断微数据包是否在第一上传窗口内；

上传控制模块83，用于在微数据包被成功接收，且微数据包在第一上传窗口内时，将微数据包确定为允许上传的微数据包；第一上传窗口用于限定允许上传的多个连续的微数据包的范围；在微数据包未被成功接收时，生成第一错误指令，并将第一错误指令发送至第一传输模块81；

第一传输模块81还用于将第一错误指令返回至发送端；第一错误指令用于指示微数据包未被成功接收，以使发送端重新传输微数据包。

由于第一上传窗口限定的允许上传的微数据包是多个连续的微数据包，因此，即便在第一上传窗口内的一个微数据包未被成功接收，也不会影响该第一上传窗口内其他微数据包的上传，基于此，只需将未被成功接收的一个微数据包重新传输即可，不需要再重新传输未被成功接收的微数据包之后被成功接收的微数据包，从而可以减少数据重传过程中带宽的损失，提高带宽的利用率。

在上述实施例的基础上，本发明一些实施例中，上传控制模块83还用于在微数据包未被成功接收，且微数据包在第一上传窗口内时，控制第一上传窗口保持不变；在重新传输的微数据包被成功接收，且重新传输的微数据包在第一上传窗口内时，将重新传输的微数据包确定为允许上传的微数据包，并按照微数据包的期望上传顺序将第一上传窗口更新为下一第一上传窗口

在上述任一实施例的基础上，本发明一些实施例中，判断模块82判断微数据包是否在第一上传窗口内包括：

判断微数据包是否在第二上传窗口内，第二上传窗口用于限定允许上传的一个微数据包的范围；第二上传窗口限定的允许上传的微数据包的范围在第一上传窗口限定的允许上传的微数据包的范围内；

若微数据包在第二上传窗口内，则微数据包在第一上传窗口内；

若微数据包不在第二上传窗口内，判断微数据包是否在第一上传窗口除第二上传窗口之外的范围内，若微数据包在第一上传窗口除第二上传窗口之外的范围内，则微数据包在第一上传窗口内。

在上述实施例的基础上，本发明一些实施例中，上传控制模块83还用于在微数据包被成功接收，且微数据包在第二上传窗口内时，按照微数据包的期望上传顺序将第二上传窗口更新为下一第二上传窗口；在微数据包未被成功接收，但微数据包在第二上传窗口内时，控制第二上传窗口保持不变；在重新传输的微数据包被成功接收，且微数据包在第二上传窗口内时，将重新传输的微数据包确定为允许上传的微数据包，并按照微数据包的期望上传顺序将第二上传窗口更新为下一第二上传窗口。

在上述实施例的基础上，本发明一些实施例中，上传控制模块83按照微数据包的期望上传顺序将第二上传窗口更新为下一第二上传窗口之后，还包括：按照微数据包的期望上传顺序将第一上传窗口更新为下一第一上传窗口。

本发明一些实施例中，判断模块82判断微数据包是否在第二上传窗口内包括：判断微数据包的序列号是否为第二上传窗口限定的允许上传的一个微数据包的序列号；

判断微数据包是否在第一上传窗口内包括：判断微数据包的序列号是否是第一上传窗口限定的允许上传的多个连续的微数据包中任一微数据包的序列号。

本发明一些实施例中，上传控制模块83在微数据包不在第二上传窗口内，但微数据包在第一上传窗口内时，将微数据包确定为允许上传的微数据包之前，还包括：

判断微数据包是否具有重复的微数据包；

若没有，将微数据包确定为允许上传的微数据包。

本发明一些实施例中，上传控制模块83还用于在微数据包不在第一上传窗口内时，生成第二错误指令，并将第二错误指令返回至发送端；其中，第二错误指令用于指示微数据包上传错误，以使发送端重新传输微数据包，或者，使发送端重新传输微数据包及其之后传输的微数据包。

本发明一些实施例中，上传控制模块83将重新传输的微数据包确定为允许上传的微数据包之后，还包括：

将在同一第一上传窗口内的重新传输的微数据包以及其他微数据包进行排序，以使重新传输的微数据包以及其他微数据包仍按照微数据包的期望上传顺序上传。

作为本发明实施例公开内容的另一种可选实现，本发明实施例提供了一种数据重传装置应用于发送端，具体应用于发送端设备。该发送端设备可以是芯片等。并且，芯片为应用片上系统的芯片。此外，芯片可以是封装后的芯片，也可以是未封装的裸片。图9示例性的示出了一种数据重传装置的结构示意图，如图9所示，该数据重传装置包括：

第二传输模块91，用于获取接收端传输的第一错误指令；第一错误指令用于指示对应的一个微数据包未被成功接收；

重传确定模块92，用于根据第一错误指令，确定重新传输的微数据包；重新传输的微数据包为第一错误指令指示未被成功接收的一个微数据包；

第二传输模块91还用于将重新传输的微数据包传输至接收端。

在上述实施例的基础上，本发明一些实施例中，重传确定模块92还用于获取超时重传指令；根据超时重传指令，确定重新传输的微数据包；超时重传指令用于指示在预设时间内未接收到对应的一个微数据包的确认指令；重新传输的微数据包为超时重传指令指示的在预设时间内未接收到确认指令的一个微数据包；第二传输模块91还用于将重新传输的微数据包传输至接收端。

在上述实施例的基础上，本发明一些实施例中，第二传输模块91还用于获取接收端传输的第二错误指令；第二错误指令用于指示对应的一个微数据包上传错误；重传确定模块92还用于根据第二错误指令，确定重新传输的微数据包；重新传输的微数据包为第二错误指令指示上传错误的一个微数据包，或，重新传输的微数据包为第二错误指令指示上传错误的一个微数据包及其之后传输的微数据包；第二传输模块91还用于将重新传输的微数据包传输至接收端。

作为本发明实施例公开内容的另一种可选实现，本发明实施例提供了一种本发明实施例还提供了一种计算机设备，包括：

存储器，存储至少一组指令；

处理器，执行至少一组指令，以执行如上任一实施例提供的数据传输方法，或者，如任一实施例提供的数据重传方法。

本发明实施例的计算机设备包括但不仅限于芯片等。该芯片可以是应用片上系统的芯片。并且，该芯片可以是封装后的芯片，也可以是未封装的裸片，在此不再赘述。

本发明实施例中，发送端芯片和接收端芯片通过片上网络进行互连通信。并且，发送端芯片和接收端芯片采用MCM(Multi-Chip Module，多层互连)技术封装。发送端芯片和接收端芯片设置在高密度多层互连基板上，采用微焊接、封装工艺将构成电子电路的各种微型元器件(芯片、裸芯片及片式元器件)组装起来，形成高密度、高性能、高可靠性的微电子产品(包括组件、部件、子系统、系统)。

作为本发明实施例公开内容的另一种可选实现，本发明实施例提供了一种可读存储介质，可读存储介质存储至少一组指令，至少一组指令用于使处理器执行如上任一实施例提供的数据传输方法，或者，如任一实施例提供的数据重传方法。

本发明实施例的可读存储介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是主机可读指令、数据结构、程序的模块或其他数据。主机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

上文描述了本发明实施例提供的多个实施例方案，各实施例方案介绍的各可选方式可在不冲突的情况下相互结合、交叉引用，从而延伸出多种可能的实施例方案，这些均可认为是本发明实施例披露、公开的实施例方案。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (17)

1.一种数据传输方法，其特征在于，应用于接收端，包括：

接收发送端传输的微数据包；

判断所述微数据包是否被成功接收，并判断所述微数据包是否在第一上传窗口内；

若所述微数据包被成功接收，且所述微数据包在第一上传窗口内，将所述微数据包确定为允许上传的微数据包；所述第一上传窗口用于限定允许上传的多个连续的微数据包的范围；

若所述微数据包未被成功接收，生成第一错误指令，并将所述第一错误指令返回至所述发送端；所述第一错误指令用于指示所述微数据包未被成功接收，以使所述发送端重新传输所述微数据包。

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

若所述微数据包未被成功接收，且所述微数据包在所述第一上传窗口内，保持所述第一上传窗口不变；

若重新传输的所述微数据包被成功接收，且重新传输的所述微数据包在所述第一上传窗口内，将所述重新传输的所述微数据包确定为允许上传的微数据包，并按照微数据包的期望上传顺序将所述第一上传窗口更新为下一第一上传窗口。

3.根据权利要求1或2所述的数据传输方法，其特征在于，判断所述微数据包是否在所述第一上传窗口内包括：

判断所述微数据包是否在第二上传窗口内，所述第二上传窗口用于限定允许上传的一个微数据包的范围；所述第二上传窗口限定的允许上传的微数据包的范围在所述第一上传窗口限定的允许上传的微数据包的范围内；

若所述微数据包在所述第二上传窗口内，则所述微数据包在所述第一上传窗口内；

若所述微数据包不在所述第二上传窗口内，判断所述微数据包是否在所述第一上传窗口除所述第二上传窗口之外的范围内，若所述微数据包在所述第一上传窗口除所述第二上传窗口之外的范围内，则所述微数据包在所述第一上传窗口内。

4.根据权利要求3所述的数据传输方法，其特征在于，所述第二上传窗口限定的允许上传的微数据包为所述第一上传窗口限定的允许上传的多个连续的微数据包中的第一个微数据包。

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

若所述微数据包被成功接收，且所述微数据包在所述第二上传窗口内，按照微数据包的期望上传顺序将所述第二上传窗口更新为下一第二上传窗口；

若所述微数据包未被成功接收，但所述微数据包在所述第二上传窗口内，保持所述第二上传窗口不变；

若重新传输的所述微数据包被成功接收，且所述微数据包在所述第二上传窗口内，将所述重新传输的所述微数据包确定为允许上传的微数据包，并按照微数据包的期望上传顺序将所述第二上传窗口更新为下一第二上传窗口。

6.根据权利要求5所述的数据传输方法，其特征在于，所述按照微数据包的期望上传顺序将所述第二上传窗口更新为下一第二上传窗口之后，还包括：按照微数据包的期望上传顺序将所述第一上传窗口更新为下一第一上传窗口。

7.根据权利要求3所述的数据传输方法，其特征在于，所述判断所述微数据包是否在第二上传窗口内包括：判断所述微数据包的序列号是否为所述第二上传窗口限定的允许上传的一个微数据包的序列号；

所述判断所述微数据包是否在所述第一上传窗口内包括：判断所述微数据包的序列号是否是所述第一上传窗口限定的允许上传的多个连续的微数据包中任一微数据包的序列号。

8.根据权利要求3所述的数据传输方法，其特征在于，若所述微数据包不在所述第二上传窗口内，但所述微数据包在所述第一上传窗口内，将所述微数据包确定为允许上传的微数据包之前，还包括：

判断所述微数据包是否具有重复的微数据包；

若没有，将所述微数据包确定为允许上传的微数据包。

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

若所述微数据包不在所述第一上传窗口内，生成第二错误指令，并将所述第二错误指令返回至所述发送端；

其中，所述第二错误指令用于指示所述微数据包上传错误，以使所述发送端重新传输所述微数据包，或者，使所述发送端重新传输所述微数据包及其之后传输的微数据包。

10.根据权利要求2所述的数据传输方法，其特征在于，所述将所述重新传输的所述微数据包确定为允许上传的微数据包之后，还包括：

将在同一第一上传窗口内的所述重新传输的所述微数据包以及其他微数据包进行排序，以使所述重新传输的所述微数据包以及所述其他微数据包仍按照微数据包的期望上传顺序上传。

11.一种数据重传方法，其特征在于，应用于发送端，包括：

获取接收端传输的第一错误指令；所述第一错误指令用于指示对应的一个微数据包未被成功接收；

根据所述第一错误指令，确定重新传输的微数据包；所述重新传输的微数据包为所述第一错误指令指示未被成功接收的一个微数据包；

将所述重新传输的微数据包传输至所述接收端。

12.根据权利要求11所述的数据重传方法，其特征在于，还包括：

获取超时重传指令；所述超时重传指令用于指示在预设时间内未接收到对应的一个微数据包的确认指令；

根据所述超时重传指令，确定重新传输的微数据包；所述重新传输的微数据包为所述超时重传指令指示的在预设时间内未接收到确认指令的一个微数据包；

将所述重新传输的微数据包传输至所述接收端。

13.根据权利要求11所述的数据重传方法，其特征在于，还包括：

获取所述接收端传输的第二错误指令；所述第二错误指令用于指示对应的一个微数据包上传错误；

根据所述第二错误指令，确定重新传输的微数据包；所述重新传输的微数据包为所述第二错误指令指示上传错误的一个微数据包，或，所述重新传输的微数据包为所述第二错误指令指示上传错误的一个微数据包及其之后传输的微数据包；

将所述重新传输的微数据包传输至所述接收端。

14.一种数据传输装置，其特征在于，应用于接收端，包括：

第一传输模块，用于接收发送端传输的微数据包；

判断模块，用于判断所述微数据包是否被成功接收，并判断所述微数据包是否在第一上传窗口内；

上传控制模块，用于在所述微数据包被成功接收，且所述微数据包在第一上传窗口内时，将所述微数据包确定为允许上传的微数据包；所述第一上传窗口用于限定允许上传的多个连续的微数据包的范围；在所述微数据包未被成功接收时，生成第一错误指令，并将所述第一错误指令发送至所述第一传输模块；

所述第一传输模块还用于将所述第一错误指令返回至所述发送端；所述第一错误指令用于指示所述微数据包未被成功接收，以使所述发送端重新传输所述微数据包。

15.一种数据重传装置，其特征在于，应用于发送端，包括：

第二传输模块，用于获取接收端传输的第一错误指令；所述第一错误指令用于指示对应的一个微数据包未被成功接收；

重传控制模块，用于根据所述第一错误指令，确定重新传输的微数据包；所述重新传输的微数据包为所述第一错误指令指示未被成功接收的一个微数据包；

所述第二传输模块还用于将所述重新传输的微数据包传输至所述接收端。

16.一种计算机设备，其特征在于，包括：

存储器，存储至少一组指令；

处理器，执行所述至少一组指令执行如权利要求1至10任一项所述的数据传输方法，或者，如权利要求11～13任一项所述的数据重传方法。

17.一种可读存储介质，其特征在于，所述可读存储介质存储至少一组指令，所述至少一组指令用于使处理器执行如权利要求1至10任一项所述的数据传输方法，或者，如权利要求11～13任一项所述的数据重传方法。

Images