一种对等网络中的任务调度方法及装置与流程

本发明涉及网络领域，尤其涉及一种对等网络中的任务调度方法及装置。

背景技术：

对等(peertopeer，p2p)是一种在对等者(peer)之间分配任务和工作负载的分布式应用架构，是对等计算模型在应用层形成的一种组网或网络形式。p2p网络系统中的每个终端，可以称为一个p2p节点。在p2p网络系统中，节点与节点之间共享资源，可以相互分享资源，比如相互之间上传和下载资源，在p2p网络中点播视频就是资源分享的一种；在一次资源分享中，下载资源的p2p节点可以称为下载节点，上传资源的p2p节点可以称为上传节点。

在服务于视频点播类的p2p网络系统中，为了保证用户播放视频的流畅性，对p2p技术有着更高的要求。

在视频点播的性能指标中，有一项指标叫卡顿率，就是在所有播放次数中，没有出现卡顿的次数比例。所谓卡顿，就是播放器按视频正常的码率播放时出现读不到数据的情况，播放中每次读不到数据就会上报一次卡顿。

在整个播放环节中，涉及到播放器，加速器，服务器，上传节点，内容分发网络(contentdeliverynetwork，cdn)等多个角色。由进行点播的p2p节点(该p2p节点作为本次资源分享中的下载节点)中的播放器，向该p2p节点中的加速器发送待播放的视频资源的统一资源定位符(uniformresourelocator，url)请求，其中，加速器可以是指p2p节点上运行的p2p程序，可以是集成在应用(app)里面的一个动态库，或者静态库，也可以是一个独立的可执行程序。

加速器收到url请求后，先从服务器获取上传节点的列表，同时将请求的资源数据切分成不同的p2p任务(后文也称为上传任务)，并向上传节点发送上传任务，再将上传节点返回的资源保存下来，实时地输出给播放器。如果因为资源没有及时下载下来，导致资源无法按正常码率输出给播放器，就会出现播放器播放卡顿的情况。

在p2p资源的下载过程中，一般会把一个资源文件拆分成很多小的上传任务，发给不同的上传资源的p2p节点(即：上传节点)；其中，每个上传任务对应于要下载的资源中的一部分。这些上传节点的服务能力是不确定的，主要表现在几个方面：a)上传节点的上传带宽不确定，有些上传节点的上传带宽高，有些上传节点的上传带宽低；b)上传节点当前正在处理的请求数不确定，如果上传节点收到的请求数多，就需要排队处理，新收到的请求就不能得到及时的响应；c)上传节点的状态不确定，这是由于用户的行为的不确定性，比如说某一上传节点正在上传，但是用户把电脑关机了，或者把加速器对应的应用程序退出了，都会造成上传节点中断服务。

由于有这些不确定因素，会导致在资源下载过程中，有部分的上传任务不能完成。对于这部分上传任务，需要回收，并再分配给其他的上传节点，以重新下载这部分资源。如果回收任务不及时，导致无法及时把这部分资源输出给播放器，最终有可能会造成卡顿。

目前，有一种回收上传任务的方法是超时回收(或称为过期回收)，即给每一个上传任务设置一个任务时间(比如10秒)。在下载资源过程中，周期性的去检查每个上传任务，如果发现某个上传任务的任务时间到了，但是数据还没有下完，就把任务回收回来，转发给其他的上传节点。

上述回收任务的方案存在以下缺陷：

一方面，当一个上传任务的任务时间到了，再重新分配该上传任务，有可能还是来不及下载完资源，仍会造成卡顿，特别是一些离播放点比较近的上传任务。

另一方面，周期性的去检查上传任务，会带来一个时间上的延迟，比如检查周期是2秒，本来在第11秒的时候就已经过期的任务，必须等到第12秒时间才能检查出来并回收，额外增加了1秒的时间，这对用户体验来讲是非常不好的。

基于以上，需要一种p2p资源下载方法，其可以减少卡顿的出现，并提高p2p网络中的资源分享性能。

技术实现要素：

本申请提供一种对等网络中的任务调度方法及装置，能够提高p2p网络中的资源分享性能。

本申请采用如下技术方案。

一种对等网络中的任务调度方法，包括：

分别根据处理中的各上传任务的处理进度信息，判断所述处理中的各上传任务是否能在任务时间内完成；其中，进行中的上传任务是已分配给上传节点但尚未完成的上传任务；

对判断为不能在任务时间内完成的上传任务进行调度。

其中，所述对判断为不能在任务时间内完成的上传任务进行调度可以包括：

回收被判断为不能在任务时间内完成的上传任务的剩余任务量，并分配给其它空闲的上传节点。

其中，所述回收判断为不能在任务时间内完成的上传任务的剩余任务量可以包括：

将判断为不能在任务时间内完成的各上传任务的剩余任务量分别作为一个上传任务，放回任务池；其中，任务池中的各上传任务按照起始点从前往后排列。

其中，所述分别根据进行中的各上传任务的处理进度信息，判断所述进行中的各上传任务是否能在任务时间内完成可以包括：

对于进行中的各上传任务分别进行判断；其中，对任一个上传任务进行的判断包括：

如果该上传任务的响应时间达到或超过预定的响应阈值，则判断该上传任务不能在任务时间内完成；其中，响应时间是指从该上传任务被发出，到接收到该上传任务所对应的第一份资源为止的时间长度。

其中，所述分别根据进行中的各上传任务的处理进度信息，判断所述进行中的各上传任务是否能在任务时间内完成可以包括：

对于进行中的各上传任务分别进行判断；其中，对任一个上传任务进行的判断包括：

如果该上传任务的剩余任务量，大于该上传任务预计完成的任务量，则判断该上传任务不能在任务时间内完成；其中，剩余任务量是该上传任务的总任务量减去当前已完成的任务量；预计完成的任务量根据当前已完成的任务量，和传输资源的时间长度得到。

其中，预计完成的任务量根据当前已完成的任务量，和传输资源的时间长度得到可以是指：

预计完成的任务量等于当前平均速度乘以剩余时间；其中，剩余时间是当前时刻距离任务时间的结束时刻的时间长度，或任务时间减去当前已经使用的时间；当前平均速度等于当前已完成的任务量除以传输资源的时间长度。

其中，所述对于进行中的各上传任务分别进行判断可以包括：

在进行中的各上传任务中，在开始接收一个上传任务对应的资源的时刻和当前时刻之间相隔的时间长度已经达到或超过预定时间长度后，对该上传任务进行判断。

一种对等网络中的任务调度装置，包括：处理器和存储器；

所述存储器用于保存用于进行任务调度的程序；所述用于进行任务调度的程序在被所述处理器读取执行时，进行如下操作：

分别根据进行中的各上传任务的处理进度信息，判断所述进行中的各上传任务是否能在任务时间内完成；其中，进行中的上传任务是已分配给上传节点但尚未完成的上传任务；

对判断为不能在任务时间内完成的上传任务进行调度。

其中，所述对判断为不能在任务时间内完成的上传任务进行调度可以包括：

将判断为不能在任务时间内完成的各上传任务的剩余任务量分别作为一个上传任务，放回任务池；其中，任务池中的各上传任务按照起始点从前往后排列；

将任务池中的上传任务依次分配给其它空闲的上传节点。

其中，所述分别根据进行中的各上传任务的处理进度信息，判断所述进行中的各上传任务是否能在任务时间内完成可以包括：

对于进行中的各上传任务分别进行判断；其中，对任一个上传任务进行的判断包括：

如果该上传任务的响应时间达到或超过预定的响应阈值，则判断该上传任务不能在任务时间内完成；其中，响应时间是指从该上传任务被发出，到接收到该上传任务所对应的第一份资源为止的时间长度。

其中，所述分别根据进行中的各上传任务的处理进度信息，判断所述进行中的各上传任务是否能在任务时间内完成可以包括：

对于进行中的各上传任务分别进行判断；其中，对任一个上传任务进行的判断包括：

如果该上传任务的剩余任务量，大于该上传任务预计完成的任务量，则判断该上传任务不能在任务时间内完成；其中，剩余任务量是该上传任务的总任务量减去当前已完成的任务量；预计完成的任务量根据当前已完成的任务量，和传输资源的时间长度得到。

其中，所述对于进行中的各上传任务分别进行判断可以包括：

在进行中的各上传任务中，在开始接收一个上传任务对应的资源的时刻和当前时刻之间相隔的时间长度已经达到或超过预定时间长度后，对该上传任务进行判断。

一种对等网络中的任务调度装置，包括：

判断模块，用于分别根据进行中的各上传任务的处理进度信息，判断所述进行中的各上传任务是否能在任务时间内完成；其中，进行中的上传任务是已分配给上传节点但尚未完成的上传任务；

调度模块，用于对判断为不能在任务时间内完成的上传任务进行调度。

其中，所述调度模块对判断为不能在任务时间内完成的上传任务进行调度可以包括：

所述调度模块将判断为不能在任务时间内完成的各上传任务的剩余任务量分别作为一个上传任务，放回任务池；其中，任务池中的各上传任务按照起始点从前往后排列；

将任务池中的上传任务依次分配给其它空闲的上传节点。

其中，所述判断模块分别根据进行中的各上传任务的处理进度信息，判断所述进行中的各上传任务是否能在任务时间内完成可以包括：

所述判断模块对于进行中的各上传任务分别进行判断；其中，对任一个上传任务进行的判断包括：

如果该上传任务的响应时间达到或超过预定的响应阈值，则判断该上传任务不能在任务时间内完成；其中，响应时间是指从该上传任务被发出，到接收到该上传任务所对应的第一份资源为止的时间长度。

其中，所述判断模块分别根据进行中的各上传任务的处理进度信息，判断所述进行中的各上传任务是否能在任务时间内完成可以包括：

所述判断模块对于进行中的各上传任务分别进行判断；其中，对任一个上传任务进行的判断包括：

如果该上传任务的剩余任务量，大于该上传任务预计完成的任务量，则判断该上传任务不能在任务时间内完成；其中，剩余任务量是该上传任务的总任务量减去当前已完成的任务量；预计完成的任务量根据当前已完成的任务量，和传输资源的时间长度得到。

其中，所述判断模块对于进行中的各上传任务分别进行判断可以包括：

所述判断模块在进行中的各上传任务中，在开始接收一个上传任务对应的资源的时刻和当前时刻之间相隔的时间长度已经达到或超过预定时间长度后，对该上传任务进行判断。

本申请至少一个实施例中，由于对上传任务是否将会超时进行了预判，因此能及时筛选出很可能无法在设置的任务时间内完成的上传任务，从而可以及时对这部分上传任务进行调度，提高这部分任务按时完成的可能性，使得整个p2p网络的资源分享性能得到提升。

本申请实施例的一种实现方式中，当上传任务对应的资源是视频时，可以减少卡顿，提高播放流畅度，从而改善用户的体验。

本申请实施例的一种实现方式中，将判断为将会超时的上传任务中的剩余任务量回收并分配给其它的上传节点，从其它的上传节点继续下载，从而可以使得原本可能超时的上传任务有较大可能在任务时间内完成，减少资源上传不及时带来的影响。该实现方式中，还可以将回收的剩余任务量作为一个上传任务，和任务池中其它的上传任务一起重新排序，这样会优先分配起始点靠前的上传任务。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

图1是实施例一的对等网络中的任务调度方法的流程图；

图2是实施例一的一种实施方式中，上传任务的执行过程示意图；

图3是实施例一的例子中上传任务的检查流程图；

图4是实施例三的对等网络中的任务调度装置的示意图。

具体实施方式

下面将结合附图及实施例对本申请的技术方案进行更详细的说明。

需要说明的是，如果不冲突，本申请实施例以及实施例中的各个特征可以相互结合，均在本申请的保护范围之内。另外，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

在一种配置中，对等网络中进行任务调度的计算设备可包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存(memory)。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。内存可能包括一个或多个模块。

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

实施例一、一种对等网络中的任务调度方法，如图1所示，包括步骤s110～s120：

s110、分别根据进行中的各上传任务的处理进度信息，判断所述进行中的各上传任务是否能在任务时间内完成；其中，进行中的上传任务是已分配给上传节点但尚未完成的上传任务；

s120、对判断为不能在任务时间内完成的上传任务进行调度。

本实施例中，一个上传任务已分配但未完成，意味着已经将该上传任务发给上传节点，但该上传任务所对应的资源还未接收完毕；比如可以是已经建立会话，而会话尚未结束的上传任务。

本实施例中，判断各上传任务是否能在任务时间内完成的一种“预判”，是对将来“超时”的可能性进行判断；也就是说，在进行判断的当前时刻，上传任务还没有超时，即设置的任务时间还未到达，就预先判断是否能在任务时间内完成，即是否将会超时。

本实施例中，一个上传任务被判断为不能在任务时间内完成并不表示该上传任务必然、一定不能在任务时间内完成，而是根据处理进度信息，可以预估出上传任务有很大可能性在将来不能在任务时间内完成。

本实施例中，由于进行预判，因此能及时筛选出很可能无法在设置的任务时间内完成的上传任务(即判断为将会超时的上传任务)，从而可以及时对这部分上传任务进行调度，提高这部分任务按时完成的可能性，使得整个p2p网络的资源分享性能得到提升。

本实施例中，当上传任务对应的资源是视频时，可以减少卡顿，提高播放流畅度，从而改善用户的体验。

本实施例中，上述节点为p2p节点，可以但不限于包括计算机、手机、平板等终端。

本实施例中，各上传任务分别是上传待分享资源中的一部分资源；其中，待分享资源可以包括待分享的文本文件、数据、音频、视频等；可以是一个完整的文件，也可以是文件中的一部分。

本实施例中，当一个p2p节点需要下载某些资源(比如但不限于点播一个视频)时，该p2p节点(针对要下载的资源而言，该p2p节点作为下载节点)可以建立一个下载任务，对所需要的资源进行请求，所需要的资源即上述待分享资源。

本实施例中，当下载节点对所需要的资源进行请求时，服务器可以根据下载节点所请求的资源的标识，查找p2p网络中保存有该资源的节点，并将所查找到的节点的信息返回给下载节点，这些所查找到的节点在本次资源分享中都可以作为上传节点。

本实施例中，待分享资源可以划分到多个上传任务中，或者也可以说，下载节点所建立的下载任务可以被划分成多个上传任务(对于下载节点而言，是“下载任务”，对于上传该资源的节点而言，是“上传任务”)；可以看出，一个上传任务所要上传的资源，是待分享资源中的一部分；比如待分享资源共有305kb，可以划分成30个大小为10kb的上传任务，和1个大小为5kb的上传任务。其中，划分方式可以单不限于按照固定大小的资源进行划分，可自行设置划分方式。

本实施例中，一个上传节点收到上传任务后，可以将该上传任务对应的资源分一次或多次发送给下载节点。

一种实现方式中，上述任务调度方法可以由需要下载资源的p2p节点执行；可以但不限于由该p2p节点中的加速器执行。其它实现方式中，上述任务调度方法也可以由需要下载资源的p2p节点中的其它模块执行。

一种实现方式中，步骤s110可以是周期性执行的步骤，即：可以周期性对进行中的各上传任务进行预判；当预判出有不能在任务时间内完成的上传任务时进行调度。

一种实现方式中，步骤s110可以是在满足预定的触发条件后执行的步骤，比如可以每当完成一个上传任务，就对由同一个下载任务拆分成的、进行中的各上传任务都进行预判；当预判出有不能在任务时间内完成的上传任务时进行调度。

一种实现方式中，可以每次预判时，对进行中的各上传任务逐个判断是否能在任务时间内完成，即每次预判都针对所有进行中的上传任务。

一种实现方式中，可以对每个进行中的上传任务分别判断是否能在任务时间内完成；即：对于每个进行中的上传任务，可以分别进行周期性预判，或者分别根据各自的触发条件进行预判。

一种实现方式中，所述步骤s120可以包括：

回收被判断为不能在任务时间内完成的上传任务的剩余任务量，并分配给其它空闲的上传节点。

本实现方式中，一个上传任务的剩余任务量可以等于该上传任务的总任务量(即上传任务所对应的资源的大小)减去已完成的任务量(即下载节点已收到的资源的大小)。比如上传任务对应于资源区间[50kb,900kb)，即总的资源量为850kb，如果下载节点当前已经收到600kb，则剩余任务量为350kb。

本实现方式中，在分配所回收的任务时，可以分配给当前是空闲状态的上传节点，比如还未分配过上传任务的上传节点，或者是所分配的上传任务已经完成的上传节点。

本实现方式中，在分配所回收的任务时，也可以在空闲的上传节点中按照预设条件挑选优先分配的对象。

其它实现方式中，也可以对判断为不能在任务时间内完成的上传任务进行其它方式的调度，比如加长任务时间等。

本实现方式的一种实施方案中，所述回收判断为不能在任务时间内完成的上传任务的剩余任务量可以包括：

将判断为不能在任务时间内完成的各上传任务的剩余任务量分别作为一个上传任务，放回任务池；其中，任务池中的各上传任务按照起始点从前往后排列。

本实施方案中，可以将任务池中的上传任务依次分配给其它空闲的上传节点，任务池中的上传任务里也包括回收剩余任务量得到的上传任务。

本实施方案中，上传任务的起始点可以是指该上传任务对应的资源区间的起点，或根据该起点计算出的时刻。比如上传任务对应于资源区间[50kb,900kb)，则50kb可以作为该上传任务的起始点；或者用50kb除以码率(假设待分享资源为视频的情况)，作为该上传任务的起始点。

本实施方案中，每个被判断为不能在任务时间内完成的上传任务，各自的剩余任务量会各作为一个上传任务；比如有上传任务a和b都被判断为不能在任务时间内完成，则上传任务a的剩余任务量作为一个上传任务，上传任务b的剩余任务量作为一个上传任务。

本实施方案中，可以在回收后对任务池中所有的上传任务按照起始点重新进行排序，也可以按照回收的上传任务的起始点，将回收的上传任务放入合适位置，比如回收的上传任务起始点是100kb，任务池中存在起始点分别为30kb、200kb、500kb的上传任务，则将回收的上传任务放在起始点为30kb的上传任务之后、起始点为200kb的上传任务之前。

本实施方案中，可以将起始点最靠前的上传任务优先进行分配，在使用周期性预判的情况下，该做法可以一定程度上弥补周期性预判所带来的时间误差。

其它实施方案中，也可以将回收得到的上传任务按照任意顺序放在任务池中。

一种实现方式中，所述步骤s110可以包括：对于进行中的各上传任务分别进行判断；其中，对任一个上传任务进行的判断包括：

如果该上传任务的响应时间达到或超过预定的响应阈值，则判断该上传任务不能在任务时间内完成；其中，响应时间是指从该上传任务被发出，到接收到该上传任务的第一份资源为止的时间长度。

本实现方式中，上传任务的处理进度信息即上传任务完成响应阶段(从发出上传任务到下载节点收到第一份资源为止)所耗费的时间，即：响应时间。

本实现方式中，第一份资源可以是指下载节点收到的、该上传任务所对应的第一个数据块或数据包等，即上传节点对于该上传任务，第一次发送的资源。

本实现方式中，可以是当一个上传任务对应的第一份资源被接收到时，触发对该上传任务进行预判。

本实现方式中，响应阈值是一个可配置的参数，可以通过经验值或实验值确定。

一种实现方式中，所述步骤s110可以包括：

对于进行中的各上传任务分别进行判断；其中，对任一个上传任务进行的判断包括：

如果该上传任务的剩余任务量，大于该上传任务的预计完成的任务量，则判断该上传任务不能在任务时间内完成；其中，剩余任务量是该上传任务的总任务量减去当前已完成的任务量；预计完成的任务量根据当前已完成的任务量，和传输资源的时间长度得到。

本实现方式中，上传任务的处理进度信息即上传任务中已完成的任务量(即下载节点已收到的资源量)和传输资源的时间长度。

其中，传输资源的时间长度可以是当前时刻，与下载节点收到第一份资源的时刻之间相隔的时间长度。

本实现方式中，可以当上传任务已经进入资源传输阶段后(即下载节点已经收到第一份资源后)，触发对上传任务的预判。

本实现方式中，预计完成的任务量可以等于：当前已完成的任务量除以传输资源的时间长度，乘以剩余时间；其中，剩余时间是当前时刻距离任务时间的结束时刻的时间长度，也可以等于任务时间减去当前已经使用的时间(包括响应时间加上传输资源的时间长度)。比如任务时间是10秒，当前已经使用7秒，则剩余时间为3秒。

其中，当前已完成的任务量除以传输资源的时间长度，得到的可以看成是当前平均速度。

本实现方式的一种实施方案中，考虑到网络传输速度可能上下浮动，为了提高准确度，可以设置成对于一个上传任务已经进行一段时间的资源传输后，再估算该上传任务预计完成的任务量。

本实施方案中，所述对于进行中的各上传任务分别进行判断可以包括：

在进行中的各上传任务中，在开始接收一个上传任务对应的资源的时刻和当前时刻之间相隔的时间长度已经达到或超过预定时间长度后，对该上传任务进行判断。

比如假设预定时间长度是2秒；在进行中的各上传任务中，时刻x接收到上传任务a对应的资源中的第一份资源，那么在时刻x+2秒后就可以触发对上传任务a的预判；在时刻y接收到上传任务b对应的资源中的第一份资源，那么在时刻y+2秒后就可以触发对上传任务b的预判；以此类推。

一种实现方式中，步骤s110可以包括：

对于进行中的各上传任务中的任一个上传任务，如果以下任一个条件成立，则判断该上传任务不能在任务时间内完成：

该上传任务的响应时间达到或超过预定的响应阈值；

该上传任务的剩余任务量，大于预计完成的任务量。

本实现方式可以看成是对前两种实现方式的综合应用，无论上传任务是响应时间较长，还是资源传输速度较慢，都可以判断成该上传任务不能在任务时间内完成。

本实现方式中，p2p网络中，对于一个上传任务的资源下载过程可以分解成以下两部分：

第一部分，是从下载节点将上传任务发送给上传节点开始，到下载节点接收到该上传节点返回的、该上传任务对应的第一份资源(可以是数据包或数据块等形式)为止的过程，即上传任务完成响应阶段；

第二部分，是从下载节点收到上传节点返回的、该上传任务对应的第一份资源开始，一直到上传任务对应的整个资源下载完毕为止的过程，即资源传输阶段。

整个上传任务的执行流程(从发出上传任务到上传任务对应的整个资源下载完毕为止的过程)如图2所示，其中，从t0到t1之间的过程是上述的第一部分，从t1到t2之间的过程是上述的第二部分。

其中，第一部分主要的耗时包括：a)上传任务本身的网络传输耗时(即：从下载节点发出上传任务，到上传节点收到该上传任务为止的耗时)；b)上传任务在上传节点的排队耗时；c)上传节点从本地磁盘读取资源时的磁盘输入输出(inputoutput，io)耗时；d)上传任务对应的资源在网络中的传输耗时四部分。

其中，网络传输耗时(即a和d部分)并不是主要耗时的部分，主要的耗时还是在b和c两部分。这部分时间，一般不能占用太长，如果占用时间太长，后面完成任务的概率会大幅度降低。

因此，本实现方式中，可以为响应时间(t0和t1之间的时间长度)设定一个阈值，即前文所述的预定的响应阈值，如果响应时间达到或超过所述预定的响应阈值，就可以确定上传任务不能在任务时间内完成，可以提前回收任务，即不用等到上传任务已经超时再进行回收。

其中，第二部分主要的耗时主要取决于网络传输的耗时，和上传节点的上传带宽，下载节点的下载带宽有直接关系。

对于第二部分，可以通过计算出的网络传输的当前平均速度，估算出上传任务能否在任务时间能完成(即：上传任务的剩余任务量，能否在任务时间的剩余时间内完成)。若通过估算确定上传任务可能无法在任务时间内完成，就可以提前回收任务。

本实现方式中，通过上述分析，可以生成两个判据：

判据1：上传任务的响应时间≥预定的响应阈值

其中，响应时间即从上传任务被发出，到收到该上传任务所对应的首份资源为止的时间。从图2看，即t1－t0，可以精确到毫秒级。

所述预定的响应阈值是一个可配置的参数，可以通过经验值或实验值确定。比如可以是通过大数据分析各个上传任务的平均响应时间，根据该平均响应时间所得到的一个经验值。

判据2：当前平均速度×剩余时间<剩余任务量

当前平均速度可以用下载节点已收到的资源量(即当前已完成的任务量)除以传输资源的时间长度(当前时刻减去t1)得到。比如t1时刻之后3秒时，计算当前平均速度，等于已收到的资源量除以3000(ms)。

本实现方式中，为避免由于初始下载时刻的网络抖动所导致的当前平均速度的误差过大，可以等收到资源2秒(其中，2秒也是一个可配参数，即上文的预定时间长度)以后计算的平均速度。也就说在收到资源2秒后，例如在2.5秒或3秒时，执行该判据2。

剩余时间，即任务时间－当前已经使用的时间(其中，当前已经使用的时间可以用当前时刻减去t0得到)，或是当前时刻距离任务时间的结束时刻的时间长度，可以精确到毫秒级。

剩余任务量，即上传任务对应的总的资源量－下载节点当前已经收到的资源量。

本实现方式中，若以上两个判据有任意一个成立，就可以将上传任务回收，或进行其它调度。

下面用一个例子说明本实施例。本例子可以应用在p2p网络中进行视频点播的场景下；包括以下过程201～206。

过程201：生成资源id

201.1p2p节点(在本实施例中，该p2p节点后称为下载节点)中的加速器，收到播放器发过来的超文本传输协议(hypertexttransferprotocol，http)形式的视频播放请求，请求中包含了视频资源的统一资源定位符(uniformresourelocator，url)，范围(range)等信息。

201.2所述加速器从201.1收到的请求中的url里提取特征信息(即：

能唯一标识上述视频资源的信息)。

201.3所述加速器根据201.2提取的特征信息，经过编码生成资源id，用来在p2p网络系统中唯一标识上述视频资源。

201.4所述加速器根据201.3生成的资源id，启动上述视频资源的下载任务。

过程202：请求节点列表

202.1所述加速器向服务器发送资源信息请求，请求以私有协议格式，请求中带上201.3生成的资源id。

202.2所述服务器收到202.1加速器发过来的资源信息请求，解析出资源id。

202.3所述服务器根据202.2解析出来的资源id，从本地资源列表中查找资源信息，包括文件大小，文件的消息摘要算法第5版(messagedigestalgorithm5，md5)值，资源对应的节点列表等信息。

202.4所述服务器将202.3查找到的资源信息，打包发送给所述加速器。

202.5所述加速器收到202.4服务器返回的资源信息包。

202.6所述加速器解析202.5收到的资源信息包，并将文件大小，节点列表等信息存到本地内存缓存中。

过程203：资源下载

203.1所述加速器根据201.1收到的range信息，和202.6收到的文件大小信息，计算出要下载的视频资源的数据区间。

203.2所述加速器根据203.1计算的数据区间，拆分出固定大小(如：10kb)的上传任务，每上传个任务设置一个任务时间(或称为过期时间)。

203.3所述加速器将203.2拆分出来的上传任务，统一放到任务池中。

203.4所述加速器从202.6存储的节点列表中取出一个上传节点。

203.5所述加速器从203.3的任务池中取出一个上传任务a，和203.4取出的上传节点的节点信息，一起生成一个会话信息，加入到当前会话列表里面。将上传任务a的任务时间记为：all_time，要下载的视频资源总的数据量(即：总任务量)记为：all_size。

203.6所述加速器(或者说下载节点)将取出的上传任务a，构造成上传任务请求发送给生成会话信息的上传节点。请求采用私有协议，内容包括了资源id，和请求的range信息等。记录对于上传任务a，发送上传任务的时间：t0。

203.7所述上传节点收到下载节点发送过来的上传任务请求。

203.8所述上传节点解析203.7收到上传任务请求，得到资源id，上传任务的range信息。

203.9所述上传节点根据203.8得到的资源id，从本地资源列表中，查找资源信息，包括文件的md5值，文件的存储路径等。

203.10所述上传节点根据203.9查到的文件存储路径，打开文件。

203.11所述上传节点根据203.10打开的文件，读取203.8获取到的range区间的数据(即：上述视频资源的数据)。

203.12所述上传节点将203.11读取的数据，返回给下载节点。

203.13所述加速器(或者说下载节点)接收203.12上传节点发过来的数据。记录对于上传任务a，接收到首块数据的时间：t1。

203.14所述加速器(或者说下载节点)继续接收上传节点发过来的数据，每次收完数据，将所接收的数据量累计进上传任务a当前接收的数据量(即当前已完成的任务量)，记为：recv_size。

203.15所述加速器(或者说下载节点)接收完一个上传任务的数据后(该上传任务完成)，重置该节点的状态为空闲状态，从会话列表中删除相应会话；从任务池中取出一个新的上传任务，和刚完成上传任务的上传节点的节点信息，一起形成一个新的会话，加入到会话列表中。

203.16所述加速器(或者说下载节点)重复步骤203.6-203.15，直到任务池中的任务都完成。

过程204：预判并回收任务；该过程如图3所示，包括步骤204.1～204.10。

204.1开始过程204。

本例中，有两种方式触发开始过程204。

一种是所述加速器在201.4启动资源下载任务时，创建定时器，并设置周期；当定时器的周期到了，就去检查203.5的会话列表中的各会话，

另一种是在203.15完成一个上传任务后，触发检查203.5的会话列表中的各会话对应的上传任务。

204.2所述加速器从204.1检查的会话列表中，取出一个会话。对于所取出的会话对应的上传任务，记录当前时间。

假设当取出的会话对应于上传任务a时，所记录的当前时间是：t3。

204.3所述加速器判断是否收到所取出的上传任务的首块数据，比如当取出的是上传任务a时，即判断是否记录了t1。若没有收到则可以直接认为成是响应时间达到或超出响应阈值，执行204.9。

当然，每收到首块数据的情况下也可以计算等待时间t3－t0，如果t3－t0达到或超过预设的等待时长，则可以认为是迟迟没有收到对于该上传任务的响应，即等待超时，此时可以将该上传任务的所有任务量作为剩余任务量，执行204.9。如果t3－t0未达到预设的等待时长，则可以等待并不断更新t3，直到收到首块数据或等待超时。

如果收到首块数据则分别执行204.4和204.6。

204.4所述加速器计算所取出的上传任务的响应时间。比如当取出的是上传任务a时，响应时间＝t1－t0。

204.5所述加速器判断响应时间是否达到或超出响应阈值(可以是一个配置参数，如：3s)。若达到或超过响应阈值，则执行204.9，如果未达到响应阈值，则进行204.10。

204.6所述加速器判断当前时间与收到首块数据之间的时间间隔是否达到或超过预定时间长度(其中，预定时间长度是一个配置参数，如：2秒)，比如对于上传任务a，即判断t3－t1是否大于或等于2秒。若t3－t1≥2秒，则执行步骤204.7，若t3－t1不大于2秒，则执行步骤204.10。

204.7所述加速器根据203.14记录的recv_size，计算当前平均速度，比如对于上传任务a，计算方法：

当前平均速度：avg_speed＝recv_size/(t3－t1)

204.8所述加速器判断按当前平均速度，能否在剩余时间内完成剩余任务量。比如对于上传任务a，判断条件：

(all_size－recv_size)>avg_speed×(all_time－(t3－t0))

其中，all_size－recv_size相当于是上传任务a的剩余任务量

其中，t3－t0相当于是上传任务a已经使用的时间，用all_time减去已经使用的时间，得到上传任务a的剩余时间。

若剩余任务量大于当前平均速度与剩余时间的乘积，即不能完成剩余任务量，则执行步骤204.9，剩余任务量如果不大于当前平均速度与剩余时间的乘积，即能完成剩余任务量，则执行步骤204.10。

204.9所述加速器计算剩余任务量，并将剩余任务量作为一个上传任务放回203.3的任务池中。比如：上传任务[20kb,30kb)的任务，只完成了6kb，剩余[26kb,30kb)的任务量，就要回收到任务池中，成为一个上传任务。进行204.11。

204.10以下两个条件满足至少一个则进行204.11。

条件一、上传任务的响应时间未达到响应阈值(相当于判据1不成立)、且根据204.8判断能完成剩余任务量(相当于判据2不成立)；

条件二、上传任务的响应时间未达到响应阈值(相当于判据1不成立)、且当前时间与收到首块数据之间的时间间隔没有达到或超过预定时间长度(相当于判据2无法执行)。

注意这里以上两个条件任一个不满足或都不满足的情况，在前面的流程中就会跳转至204.9。

204.11判断会话是否遍历完成；如果完成则返回步骤204.2，即所述加速器从204.1的会话列表中，取出下一个会话并进行判断。如果所有会话都已检查完毕，则结束过程204。

过程205：任务再分配

205.1所述加速器对于204.9中回收过任务后的任务池，重新根据上传任务的起始点排序。比如：

[26kb,30kb),[60kb,70kb),[70kb,80kb)...

205.2所述加速器根据203.15已完成上传任务的，标识为空闲状态的上传节点，和从205.1重新排序后的任务池中取出的任务，重新生成一个新的会话，加入到当前会话列表里面。

205.3所述加速器根据205.2重新生成的新会话，再执行步骤203.6-205.2，直到最后205.1中的任务池为空，即上述视频资源已全部下载完成。

实施例二、一种对等网络中的任务调度装置，包括：处理器和存储器；

所述存储器用于保存用于进行任务调度的程序；所述用于进行任务调度的程序在被所述处理器读取执行时，进行如下操作：

分别根据进行中的各上传任务的处理进度信息，判断所述进行中的各上传任务是否能在任务时间内完成；其中，进行中的上传任务是已分配给上传节点但尚未完成的上传任务；

对判断为不能在任务时间内完成的上传任务进行调度。

一种实现方式中，所述对判断为不能在任务时间内完成的上传任务进行调度可以包括：

回收被判断为不能在任务时间内完成的上传任务的剩余任务量，并分配给其它空闲的上传节点。

本实现方式中，所述对判断为不能在任务时间内完成的上传任务进行调度可以包括：

将判断为不能在任务时间内完成的各上传任务的剩余任务量分别作为一个上传任务，放回任务池；其中，任务池中的各上传任务按照起始点从前往后排列。

其中，可以将任务池中的上传任务依次分配给其它空闲的上传节点。

一种实现方式中，所述分别根据进行中的各上传任务的处理进度信息，判断所述进行中的各上传任务是否能在任务时间内完成可以包括：

对于进行中的各上传任务分别进行判断；其中，对任一个上传任务进行的判断可以包括：

如果该上传任务的响应时间达到或超过预定的响应阈值，则判断该上传任务不能在任务时间内完成；其中，响应时间是指该从上传任务被发出，到接收到该上传任务所对应的第一份资源为止的时间长度。

一种实现方式中，所述分别根据进行中的各上传任务的处理进度信息，判断所述进行中的各上传任务是否能在任务时间内完成可以包括：

对于进行中的各上传任务分别进行判断；其中，对任一个上传任务进行的判断可以包括：

如果该上传任务的剩余任务量，大于该上传任务预计完成的任务量，则判断该上传任务不能在任务时间内完成；其中，剩余任务量是该上传任务的总任务量减去当前已完成的任务量；预计完成的任务量根据当前已完成的任务量，和传输资源的时间长度得到。

本实现方式中，预计完成的任务量可以等于当前平均速度乘以剩余时间；其中，剩余时间是当前时刻距离任务时间的结束时刻的时间长度，或任务时间减去当前已经使用的时间；当前平均速度等于当前已完成的任务量除以传输资源的时间长度。

本实现方式中，所述对于进行中的各上传任务分别进行判断可以包括：

在进行中的各上传任务中，在开始接收一个上传任务对应的资源的时刻和当前时刻之间相隔的时间长度已经达到或超过预定时间长度后，对该上传任务进行判断。

本实施例中，所述用于进行任务调度的程序在被所述处理器读取执行时，所进行的操作可以对应于实施例一中的步骤s110～s120，所进行的操作的其它实现细节可参见实施例一。

实施例三、一种对等网络中的任务调度装置，如图4所示，包括：

判断模块31，用于分别根据进行中的各上传任务的处理进度信息，判断所述进行中的各上传任务是否能在任务时间内完成；其中，进行中的上传任务是已分配给上传节点但尚未完成的上传任务；

调度模块32，用于对判断为不能在任务时间内完成的上传任务进行调度。

一种实现方式中，所述调度模块对判断为不能在任务时间内完成的上传任务进行调度可以包括：

所述调度模块回收被判断为不能在任务时间内完成的上传任务的剩余任务量，并分配给其它空闲的上传节点。

本实现方式中，所述调度模块对判断为不能在任务时间内完成的上传任务进行调度可以包括：

所述调度模块将判断为不能在任务时间内完成的各上传任务的剩余任务量分别作为一个上传任务，放回任务池；其中，任务池中的各上传任务按照起始点从前往后排列。

其中，所述调度模块可以将任务池中的上传任务依次分配给其它空闲的上传节点。

一种实现方式中，所述判断模块分别根据进行中的各上传任务的处理进度信息，判断所述进行中的各上传任务是否能在任务时间内完成可以包括：

所述判断模块对于进行中的各上传任务分别进行判断；其中，对任一个上传任务进行的判断可以包括：

如果该上传任务的响应时间达到或超过预定的响应阈值，则判断该上传任务不能在任务时间内完成；其中，响应时间是指从该上传任务被发出，到接收到该上传任务所对应的第一份资源为止的时间长度。

一种实现方式中，所述判断模块分别根据进行中的各上传任务的处理进度信息，判断所述进行中的各上传任务是否能在任务时间内完成可以包括：

所述判断模块对于进行中的各上传任务分别进行判断；其中，对任一个上传任务进行的判断可以包括：

如果该上传任务的剩余任务量，大于该上传任务预计完成的任务量，则判断该上传任务不能在任务时间内完成；其中，剩余任务量是该上传任务的总任务量减去当前已完成的任务量；预计完成的任务量根据当前已完成的任务量，和传输资源的时间长度得到。

本实现方式中，预计完成的任务量可以等于当前平均速度乘以剩余时间；其中，剩余时间是当前时刻距离任务时间的结束时刻的时间长度，或任务时间减去当前已经使用的时间；当前平均速度等于当前已完成的任务量除以传输资源的时间长度。

本实现方式中，所述判断模块对于进行中的各上传任务分别进行判断可以包括：

所述判断模块在进行中的各上传任务中，在开始接收一个上传任务对应的资源的时刻和当前时刻之间相隔的时间长度已经达到或超过预定时间长度后，对该上传任务进行判断。

本实施例中，所述判断模块和调度模块所进行的操作可以分别对应于实施例一中的步骤s110、s120，所进行的操作的其它实现细节可参见实施例一。

本领域普通技术人员可以理解上述方法中的全部或部分步骤可通过程序来指令相关硬件完成，所述程序可以存储于计算机可读存储介质中，如只读存储器、磁盘或光盘等。可选地，上述实施例的全部或部分步骤也可以使用一个或多个集成电路来实现。相应地，上述实施例中的各模块/单元可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。本申请不限制于任何特定形式的硬件和软件的结合。

当然，本申请还可有其他多种实施例，在不背离本申请精神及其实质的情况下，熟悉本领域的技术人员当可根据本申请作出各种相应的改变和变形，但这些相应的改变和变形都应属于本申请的权利要求的保护范围。