CN102223288A - 资源调度方法、***、装置 - Google Patents

Abstract

本发明公开了一种资源调度方法、***、装置，其中，该方法包括：资源请求方根据当前数据分片的资源提供方信息与至少一个资源提供方协商数据传输，接收资源提供方返回的当前数据分片的相关分片信息；资源请求方保存相关分片信息与资源提供方的对应关系，在请求数据分片时从对应关系查询资源提供方信息。本发明可以从本地获得提供方信息进而协商数据传输，减少向索引服务器查询相关分片的资源提供方信息的检索资源消耗，解决现有技术中的启动时延大及服务器负荷重方面的技术问题。

Description

资源调度方法、***、装置

技术领域

本发明涉及网络通信领域，特别涉及一种资源调度方法、***、装置。

背景技术

网络应用中用户共享数据资源的需求日益增多，如：单纯的数据文件共享，点播时的数据共享等。现有的流媒体***(点播和直播***)中，将媒体资源按照固定大小分成多个数据块(如chunk或更小的数据块)，用于资源的发布及检索；索引器(Tracker)处理资源提供方的发布请求，保存媒体资源索引，并面向资源请求方提供检索服务。点对点(Peer to Peer，简称P2P)网络的动态特性以及用户的录放机(Video Cassette Recorder，简称VCR)行为决定了数据资源的提供方、请求方以及Tracker服务器上的媒体资源索引都是不断变化的，因此资源的调度方式对流媒体***的性能至关重要。

图1为现有技术中的流媒体调度流程示意图，如图1所示的P2P流媒体***中，媒体资源的调度全部由Tracker服务器完成，调度过程包括：对等体A(Peer A)作为资源请求方向Tracker服务器发起“Announce”请求，例如请求媒体资源(Movie X，Chunk Y)，Tracker服务器返回包含该媒体资源的对等体列表(Peer List)给对等体A，对等体A向拥有资源的对等体B(资源提供方或资源拥有方)和对等体C协商数据传输。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：图1所示的流媒体***主要是本地调度，即资源请求方从Tracker服务器获取大量的包含所请求数据分片(如Chunk Y)的资源提供方信息(即对等体列表Peer List)，然后请求方不断地与资源提供方尝试连接以实现媒体数据传输，会造成启动时延较大。请求方在下载后续数据分片(如Chunk Z)时，需要重新向Tracker服务器发送媒体请求(Movie X，Chunk Z)，由于Tracker服务器的资源检索消耗非常大，因此频繁请求检索会造成负荷严重，并且此种方式在保证用户流媒体体验的连续性方面存在不足。

发明内容

本发明的第一目的是提出一种资源调度方法，以实现高效调度。

本发明的第二目的是提出一种资源调度***，以实现高效的资源调度。

本发明的第三目的是提出一种资源调度装置，以实现在对等体资源请求侧实现高效调度。

本发明的第四目的是提出一种资源调度装置，以实现在对等体资源提供侧实现高效调度。

本发明的第五目的是提出一种资源调度装置，以实现在服务器侧实现高效调度。

为实现上述第一目的，根据本发明的一个方面，提供了一种资源调度方法，包括：资源请求方根据当前数据分片的资源提供方信息与至少一个资源提供方协商数据传输，接收资源提供方返回的当前数据分片的相关分片信息；资源请求方保存相关分片信息与资源提供方的对应关系，在请求数据分片时从对应关系查询资源提供方信息。

优选地，相关分片可以包括：当前数据分片的一至多个后续分片和/或当前数据分片的一至多个前续分片。数据分片可以包括：数据块Chunk或数据片Piece。

优选地，资源请求方与资源提供方可以通过Tracker服务器转发数据协商信令。

优选地，Tracker服务器转发数据协商信令还可以包括：Tracker服务器通过会话消息监测资源请求方与资源提供方的数据协商，在预设时间内未收到资源提供方的反馈信息时，向资源请求方发送通知消息；通知消息包括根据资源提供方的未反馈信息更新对应关系或删除资源提供方。

其中，Tracker服务器转发数据协商信令还可以包括：Tracker服务器监测到资源请求方对同一数据分片的多次请求或者预设时间内未收到资源请求方的会话请求对应的拆除连接信令时，主动向资源请求方返回当前数据分片的资源提供方信息和/或调整相应资源提供方的优先级。

优选地，资源请求方根据当前数据分片的资源提供方信息与至少一个资源提供方协商数据传输还可以包括：资源请求方根据资源提供方信息确定所有资源提供方数目n，将当前所请求的数据分片划分为不大于n的m个数据片，选择m个资源提供方并发协商数据传输。

优选地，资源提供方返回当前数据分片的相关分片信息可以包括：资源提供方接收资源请求方的当前数据分片会话请求，在会话应答消息中携带相关分片信息。

其中，还包括：资源请求方从对应关系未查询到所请求数据分片的资源提供方信息时，从索引服务器查询所请求数据分片的资源提供方信息。

其中，资源请求方与资源提供方可以位于P2P流媒体***，包括直播和点播***。

为实现上述第二目的，根据本发明的另一个方面，提供了一种资源调度***，包括：

资源请求方，用于根据当前数据分片的资源提供方信息与至少一个资源提供方协商数据传输；接收资源提供方返回的当前数据分片的相关分片信息，保存相关分片信息与资源提供方的对应关系，在请求数据分片时优从对应关系查询资源提供方信息；

资源提供方，用于与资源请求方协商数据传输，根据资源请求方的当前数据分片请求返回相关分片信息。

优选地，还可以包括：Tracker服务器，用于根据资源请求方的数据分片请求，返回资源提供方信息；接收资源请求方的会话请求发送至资源提供方，并将源提供方返回的相关分片信息发送至资源请求方。

Tracker服务器可以包括：存储模块，用于存储数据分片对应的资源提供方信息；查询模块，用于根据资源请求方的当前数据分片请求，从存储模块查询当前数据分片的资源提供方信息；信令协商模块，用于接收资源请求方的会话请求发送至资源提供方，并将源提供方返回的相关分片信息发送至资源请求方；监测模块，用于监测到资源请求方与资源提供方的传输质量低于预设条件时，向资源请求方发送当前数据分片的资源提供方信息和/或调整对应资源提供方的优先级。

优选地，Tracker服务器可以包括：判别模块，用于当资源提供方信息中的资源提供方数目小于预设值时，向媒体服务器发送包含资源请求方及当前数据分片的资源调度请求；该***还可以包括：媒体服务器，用于接收Tracker服务器的资源调度请求，向资源请求方返回包含当前请求的数据分片的资源提供方信息。

为实现上述第三目的，根据本发明的另一个方面，提供了一种资源调度装置，包括：获取模块，用于对应关系获取当前数据分片的资源提供方信息；信令协商模块，用于根据资源提供方信息与至少一个资源提供方信令协商数据传输，接收资源提供方返回的当前数据分片的相关分片信息；存储模块，用于保存当前数据分片的资源提供方信息，及相关分片与资源提供方的对应关系信息。

该装置可以位于P2P流媒体***的对等体Peer中。

该装置的获取模块还可以进一步从索引服务器或媒体服务器查询当前数据分片的资源提供方信息。

该装置还可以包括：维护模块，用于与Tracker服务器通过维护消息获取资源提供方的数据分片信息，对存储模块进行更新。或者还可以包括：分组模块，用于根据资源提供方信息确定当前数据分片的所有资源提供方数目n，将当前所请求的数据分片划分为不大于n的m个数据片；选择m个资源提供方并发协商数据传输。或者还可以包括：查询模块，用于从存储模块获取请求的数据分片的资源提供方信息，从Tracker服务器查询所请求的数据分片的资源提供方信息，从两组资源提供方信息中选择一至多个资源提供方协商数据传输。

该装置还可以包括：查询模块，用于从对应关系查询当前请求的数据分片的资源提供方信息获得资源提供方信息；否则通过索引服务器查询资源提供方信息。

为实现上述第四目的，根据本发明的另一个方面，提供了另一种资源调度装置，包括：接口模块，用于接收当前数据分片的数据协商消息，返回当前数据分片的相关分片信息；查询模块，用于根据当前数据分片信息查找相关分片信息；存储模块，用于存储各数据分片的数据内容。

该装置可以位于P2P流媒体***的对等体Peer中，接口模块可以在资源请求方的当前数据分片的会话应答消息中携带相关分片信息。

为实现上述第五目的，根据本发明的再一个方面，提供了再一种资源调度装置，包括：存储模块，用于存储数据分片对应的资源提供方信息；查询模块，用于根据资源请求方的当前数据分片请求，从存储模块查询当前数据分片的资源提供方信息，返回资源请求方；信令协商模块，用于接收资源请求方的会话请求并发送至资源提供方，并将源提供方返回的相关分片信息发送至资源请求方。

该装置可以位于P2P流媒体***的Tracker服务器内部。

该装置可以包括：监测模块，用于监测信令协商模块的传输质量，监测到资源请求方与资源提供方的传输质量低于预设条件时，向资源请求方发送当前请求的数据分片的资源提供方信息和/或调整资源提供方的优先级。以及判别模块，用于当查询模块查找的资源提供方信息中的资源提供方数目小于预设值时，向媒体服务器发送包含资源请求方及当前所请求数据分片的资源调度请求。

本发明各实施例的资源调度方法、***、装置，由于资源请求方与提供方进行数据协商时，资源提供方可以将其中保存的当前数据的相关分片信息返回给请求方，因此，在进行后续数据分片下载时，可以直接从本地获得提供方信息进而协商数据传输，减少向Tracker服务器查询数据分片的资源提供方信息的检索资源消耗，不仅提高了资源调度的效率，而且减少了Tracker服务器的负荷及调度***的稳定性，也可提高用户流媒体体验的连续性。

本发明还有些优选实施例可以实现并发数据传输，提高数据传输的效率和传输速度；另有些实施例可以通过Tracker服务器监控数据协商质量及稳定，提高数据传输质量，防止数据分片的遗失等，并且还可以采用多种方式更新本地的数据存储以进行数据分片的调度。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1为现有技术中的流媒体调度流程示意图；

图2为根据本发明资源调度方法实施例一流程图；

图3为根据本发明资源调度方法实施例二流程图；

图4为根据本发明资源调度方法及资源调度***解析实施例一示意图；

图5为根据本发明资源调度方法实施例三流程图；

图6为根据本发明资源调度方法及资源调度***解析实施例二示意图；

图7为根据本发明资源调度方法实施例四流程图；

图8为根据本发明资源调度方法及资源调度***解析实施例三示意图；

图9为根据本发明资源调度装置实施例一的示意图；

图10为根据本发明资源调度装置实施例二的示意图；

图11为根据本发明资源调度装置实施例三的示意图；

图12为根据本发明资源调度装置实施例四的示意图；

图13为根据本发明资源调度装置实施例五的示意图；

图14为根据本发明资源调度装置实施例六的示意图。

具体实施方式

图2为根据本发明资源调度方法实施例一流程图，如图1所示，本实施例包括：

步骤S102：资源请求方获取包含当前请求的数据分片的资源提供方信息，如从P2P流媒体***的Tracker服务器获取包含所请求的数据块(Chunk)或者数据片(Piece)级别数据分片的“Peer list”列表；

步骤S104：资源请求方根据获取的该资源提供方信息与至少一个资源提供方协商数据传输：在协商数据传输时，资源提供方接收请求方的当前数据分片请求，返回当前数据分片的相关分片信息；

相关分片可以包括：当前数据分片的一至多个后续分片和/或当前数据分片的一至多个前续分片；

如所请求当前数据分片为Movie A的Chunk 1，资源提供方在接收到该请求时，查询到自身还拥有后续的分片，如Chunk 2，Chunk 3，则向请求方返回Chunk 1的相关分片信息Chunk 2，Chunk 3；

步骤S106：资源请求方保存资源提供方返回的相关分片信息，保存对应关系，在需要下载数据分片时，优先查询本地的对应关系获取数据分片的资源提供方进行协商数据传输。

本实施例在协商数据传输时，资源提供方将自身拥有的，当前数据分片的相关分片信息也返回资源请求方，从而资源请求方保存这些相关分片信息与资源提供方的对应关系，并在需要下载数据分片时，优先直接从本地获取资源提供方以协商数据传输，因此可以减少上级服务器(如Tracker服务器)的查询检索消耗，减少服务器的查询次数及负荷，提高***稳定性。由于在需要下载数据分片时可以直接从本地调取资源提供方信息，可以减少用户等待时间，提高用户体验。

将图1所示的现有技术中的本地调度策略变为基于Tracker的数据块调度虽然可以加快启动时延，流媒体体验也更好，但是这种调度的媒体资源颗粒度较细，每个数据块都必须查询Tracker获取Peer List，不断的资源检索请求会加重Tracker服务器负荷，Tracker的处理能力可能成为调度的性能瓶颈，一旦Tracker服务器瘫痪，会影响整个调度和用户体验。下面的图3-图4实施例提供了一种混合资源调度方法。

图3为根据本发明资源调度方法实施例二流程图，如图3所示，本实施例包括：

步骤S202：资源请求方从本地存储的对应关系查询当前请求的数据分片的资源提供方信息，当查询不到时从Tracker服务器查询当前请求的数据分片的资源提供方信息；

步骤S204：资源请求方根据该资源提供方信息与其中的资源提供方通过Tracker服务器进行协商数据传输，Tracker服务器只负责转发数据协商信令，由于此操作在资源消耗方面比通过Tracker服务器进行查询检索资源提供方信息小得多，因此，不会加重Tracker服务器的负担。

在通过Tracker服务器转发数据协商信令时，资源提供方返回当前请求的数据分片的相关分片信息；

步骤S206：资源请求方保存各资源提供方返回的相关分片信息，保存对应关系，在需要下载数据分片时，优先查询本地的对应关系获取资源提供方并协商数据传输。

图2实施例说明了提供方返回相关分片信息，并在请求方维护相关分片及资源提供方的对应关系，但具体应用时本实施例通过Tracker服务器转发数据协商信令，而不是如图1所示由资源请求方与所有的资源提供方尝试连接以实现数据传输，可以减少与提供方之间的连接尝试次数，有利于降低启动时延，并且请求数据分片时如果上一次数据分片的提供方也是后续分片的拥有方，可以直接与该提供方协商，可以提高用户在P2P点播方面的流媒体体验。

图4为根据本发明资源调度方法及资源调度***解析实施例一示意图，如图4所示，调度过程包括：

(1)资源请求方Peer A向Tracker服务器发送请求信令Get(Movie A，Chunk 1)，查询资源(Movie A，Chunk 1)的拥有者；

(2)Tracker服务器通过请求应答信令(GetAck)返回资源提供方信息，如提供方列表(Peer List)给资源请求方Peer A，Peer List显示Peer B为媒体资源(Movie A，Chunk 1)的拥有者；

(3)请求方Peer A将Tracker服务器返回的Peer List存储在本地资源数据库“当前Chunk”数据表内，如Chunk 1：Peer B，Peer C，Peer D…；

(4)请求方Peer A通过Tracker服务器转发数据协商信令，向资源提供方Peer B发起会话请求“Setup”，协商媒体数据下载；

(5)如果资源提供方Peer B除了能够提供当前的媒体资源(Movie A，Chunk 1)，还能提供其相关数据分片，如Chunk 2，3，4，于是可以在会话应答信令“SetupAck”内携带相关分片信息，经过Tracker服务器转发给资源请求方Peer A；

(6)Peer A根据SetupAck信令携带的相关分片资源信息更新本地媒体资源数据库内“相关Chunk”数据表，如Chunk 2以及Chunk 3的资源提供方列表；

(7)Peer A完成媒体资源(Movie A，Chunk 1)下载后，如果还需下载数据分片，如Chunk 2，则优先从本地资源数据库内查找(Movie A，Chunk 2)的资源提供者，重复(4)-(7)类似的操作完成相关数据分片的资源下载，如果在本地资源数据库没有查询到当前请求的数据分片的资源提供方信息，则再请求Tracker服务器进行资源调度。

在本实施例中，资源请求方在本地负责存储一个基于数据分片的资源数据信息，如以本地数据库形式，用于存储资源提供方信息。当第一次请求数据分片的资源提供方信息时由资源请求方通过Get信令以Peer List形式从Tracker服务器查询后获得，后续请求的数据分片的资源提供方信息可以从本地获取，如本地未存储则向Tracker服务器查询获得，本实施例是一种基于Tracker服务器查询第一次请求的数据分片和资源请求方本地查询后续请求数据分片的混合资源调度，与现有技术相比，能够减少与资源提供方之间的连接尝试次数，有利于降低启动时延，并且本地资源数据库的引入能够大大降低资源检索对Tracker服务器的资源消耗，减轻服务器负荷。

本实施例以数据块Chunk为例，本领域技术人员应了解，比数据块“Chunk”更小的数据片，如“Piece”仍可适用本发明的各实施例。

本实施例的资源调度***包括：

资源请求方，用于根据资源提供方信息通过Tracker服务器或直接与至少一个资源提供方协商数据传输；接收资源提供方返回的当前数据分片的相关分片信息，保存相关分片信息与各资源提供方的对应关系，在请求数据分片时优先从对应关系查询资源提供方信息。资源请求方相关功能可参见图4中的Peer A；

Tracker服务器，用于根据资源请求方的当前数据分片请求，返回当前数据分片的资源提供方信息；该服务器还可以转发请求方与提供方之间的数据协商信令，具体参见图4；

资源提供方，用于根据资源请求方的当前数据分片请求返回当前数据分片的相关分片信息，资源提供方相关功能可参见图4中的Peer B。

图4中通过Tracker服务器进行数据协商，还可以进一步优化：

资源调度优化方式一：

资源请求方根据Peer list确定所有资源提供方的数目n，将当前所请求的数据分片划分为m(m≤n)个更小的数据片，选择m个资源提供方并发协商数据传输。如图4中，Chunk 1的提供方包括四个节点Peer B、PeerC、Peer D、Peer G，则请求方Peer A将Chunk 1分为4个Piece，分别为Piece1-Piece4，请求方Peer A通过Tracker服务向这4个提供方发起并发请求，如向Peer B请求下载Chunk1的Piece1，…向PeerG请求下载Chunk1的Piece4。当然，请求方Peer A也可以将Chunk 1分为2个Piece，分别为Piece1-Piece2，并从4个提供方中选择2个优先级高的请求方，通过Tracker服务向这2个提供方发起并发请求，如选择向Peer B和Peer C分别请求下载Chunk1的Piece1及Piece2。此优化方式也适用后续数据分片的调度，如在下载Chunk 2时也可以根据提供方数目进行分组，并并发发送数据协商请求，这种方式可以提高下载的速度。

资源调度优化方式二：

如图4步骤(2)中，资源请求方通过Tracker服务器查询请求的当前数据分片的资源提供方信息；当Tracker服务器查询后确定资源提供方信息中的资源提供方数目小于预设值时，如当前数据分片的Peer list中只有一个提供方，则Tracker服务器通知上级的媒体服务器为Peer A进行资源调度，通过媒体服务器返回当前数据分片的更多资源提供方信息。此种资源调度可以提高调度的有效性，如果资源提供方数据较少，则有可能在协商数据传输过程不成功，通过媒体服务器进行资源调度可提高资源调度的成功率和稳定性。

资源调度优化方式三：

图4中，Peer B接收到Peer A的当前数据分片会话请求，可以在会话应答消息“SetupAck”中携带相关分片信息，从而使请求方Peer A获得相关分片资源提供方信息。在实际应用时，也可以通过后续的消息获得，如利用请求方Peer A和Tracker服务器间周期性的维护消息，如保活信令“KeepAlive”来更新存储的对应关系，如本地资源数据库，例如Peer A可以通过“KeepAlive”信令周期性地要求Tracker服务器返回资源提供者PeerB拥有的数据分片信息，此操作在资源消耗方面比通过Get信令检索(Movie X，Chunk Y)的资源提供方要小得多，可以加速对应关系的更新。

资源调度优化方式四：

由于图4实施例通过Tracker服务器转发数据协商信令，因此可以利用Tracker服务器监测协商质量，并及时进行资源调整，例如下述两种情况下的资源调度调整：

①Tracker服务器通过会话消息“Setup”信令监测资源请求方与资源提供方的数据协商，在预设时间内未收到资源提供方的会话应答“SetupAck”时，此时资源提供方可能已经离开此流媒体***，因此，Tracker服务器向资源请求方发送通知消息，如：通知请求方更新本地资源数据库或直接在本地数据库中删除该资源提供方。

②Tracker服务器通过会话消息监测资源请求方与资源提供方的数据协商；当监测到某个资源请求方对同一数据分片资源的多次请求，说明传输链路不佳，存在重传；或者当监测到在预设时间内未收到会话请求“Setup”对应的拆除连接(Teardown)信令时，说明媒体传输失败。在这两种情况的类似场景下，Tracker服务器监测到传输质量下降，可以主动向资源请求方返回当前请求的数据分片的资源提供方信息，并调整相应资源提供方的优先级，例如：通过维护消息“KeepAlive”保活信令进行主动调度，返回一组Peer List给资源请求方，并通知资源请求方降低传输质量下降的资源提供方的优先级。

资源调度优化方式五：

图4实施例提供了一种减少Tracker服务器负荷、提高***稳定性的通过Tracker服务器首次查找，和请求方进行数据分片的本地查找的混合调度方式，但如图4所示，当前Chunk1的提供方返回的相关分片均不包含C hunk2，则在请求C hunk2时，本地对应关系无法查找到，此时为了提高查找和下载效率，图4流程的第(7)步可以修改为：Peer A完成资源(MovieA，Chunk 1)下载后，并发执行两个操作：1)从本地查找(Movie A，Chunk 2)的资源提供方；2)从Tracker服务器请求查找(Movie A，Chunk 2)的资源提供方，获得这些查询结果后，PeerA根据预设的原则优先选择稳定且速度快的资源提供方，然后重复(4)-(7)完成Chunk 2的资源下载。

图4实施例以及附加的五种资源调度优化方式可以增强网络侧的可控可管性，并及时通过Tracker服务器监控传输质量，及时调整调度策略。

图5为根据本发明资源调度方法实施例三流程图；如图5所示，本实施例包括：

步骤S302：资源请求方查询当前数据分片的资源提供方信息；

步骤S304：资源请求方根据该资源提供方信息与其中的资源提供方直接进行协商数据传输，资源提供方返回当前请求的数据分片的相关分片信息；

步骤S306：资源请求方保存资源提供方返回的相关分片信息，保存对应关系。

本实施例与图3类似，唯一的是数据协商信令直接由资源提供方和请求方进行，不需要Tracker服务器转发，可以减少Tracker服务器的转发信令交互，减少Tracker服务器的压力，且在本地查询到数据分片的资源提供方信息后，直接与提供方进行数据协商。

图6为根据本发明资源调度方法及资源调度***解析实施例二示意图，图6与图4的过程类似，区别在于数据协商过程(4-(7))直接由资源提供方和请求方进行，不需要Tracker服务器转发，此时Tracker服务器不需要监控资源提供方和请求方的信令协商过程。

图6中，在Peer A从当前数据分片的资源提供方协商后获得相关分片信息后，保存在本地对应关系中，在需要下载数据分片，如Chunk 2时，Peer A若从本地资源数据库查询后，确定Chunk 2保存在上次数据传输的资源提供方Peer B内，则与Peer B直接协商数据传输；或者如图4的资源调度优化方式一一样，根据当前请求数据分片的资源提供方数目，进行并发协商数据传输。

图7为根据本发明资源调度方法实施例四流程图；如图7所示，本实施例包括：

步骤S402：资源请求方查询当前数据分片的资源提供方信息，从本地存储的对应关系中或索引服务器中获得资源提供方列表；

步骤S404：资源请求方根据该资源提供方信息中的资源提供方数目发起并发协商数据传输，资源提供方返回当前数据分片的相关分片信息；

步骤S406：资源请求方保存资源提供方返回的相关分片信息，保存对应关系，在需要下载数据分片时，优先查询本地的对应关系获取资源提供方以协商数据传输。

本实施例与图4的资源调度优化方式一类似，但是本实施例的数据并发协商数据传输可以通过Tracker服务器转发，也可以由资源提供方和请求方直接协商；本实施例不仅可以在首次请求的数据请求采用此分组方式进行并发协商，也可以在后续请求的数据分片时进行并发协商，其应用场景不唯一。

图8为根据本发明资源调度方法及资源调度***解析实施例三示意图。如图8所示，本实施例步骤(1)-(3)与图4实施例一样，步骤(4)-(7)的数据协商与图4类似，可以通过Tracker服务器转发，也可以请求方Peer A直接与提供方协商。图8实施例只画出了直接协商示意图，本实施例当前数据分片Chunk1采用并发的协商方式，相关分片Chunk2也采用并发的协商方式，Chunk3采用只于一个提供方协商的方式，最终获取数据的内容为：

1.Chunk 1分为3Piece，分别从Peer B、Peer D、Peer C并发下载；

2.Chunk 2分为2Piece，分别从Peer B、Peer C并发下载；

3.Chunk 3只从Peer B下载。

本领域技术人员应了解，本发明中的资源请求方与资源提供方可以位于P2P流媒体***，上述各方法实施例中，在首次请求资源提供方信息，如Chunk1的提供方时可以通过Tracker服务器获取；后续的相关分片如Chunk2、3…的资源提供方信息可以从资源请求方的本地数据库获取；此时数据分片Chunk2、3…为当前所请求的数据分片，由于资源提供方可能随时离开***，也可能保存的资源有所更新，因此，在后续数据分片成为当前请求的数据分片时，仍旧可以通过提供方返回的会话应答消息获得更新的相关分片信息，或者资源请求方与Tracker服务器通过维护消息更新本地对应关系的数据分片信息。

本发明上述各实施例提出的基于Tracker服务器和普通对等体之间的混合资源调度方法及***，与现有技术相比，能够减少与资源提供方之间的连接尝试次数，有利于降低启动时延，并且本地资源数据库的引入能够大大降低资源检索对Tracker服务器的资源消耗，此外利用“SetAck”、“KeepAlive”等信令可以快速更新本地资源数据库，以及Tracker服务器监测传输质量实施主动调度，在降低Tracker节点的负荷和保证用户流媒体体验方面均具有明显优势。

图9为根据本发明资源调度装置实施例一的示意图，图9所示的装置主要应用与资源请求方一侧，可以位于流媒体***的对等体Peer中，并置于P2P流媒体***中。如图9所示，本实施例包括：

获取模块2，用于从索引服务器、媒体服务器或存储模块的对应关系查询当前数据分片的资源提供方信息；

信令协商模块4，用于根据资源提供方信息与资源提供方信令协商数据传输，接收资源提供方返回的当前数据分片的相关分片信息；

存储模块6，用于保存当前数据分片的资源提供方信息，及相关分片与资源提供方的对应关系信息，可以本地资源数据库的形式存在。

其中，相关分片可以包括：当前数据分片的一至多个后续分片和/或当前数据分片的一至多个前续分片。数据分片可以包括：数据块Chunk或更小的数据片Piece。

图10为根据本发明资源调度装置实施例二的示意图，图10是对图9的细化，并增加了如下模块：

维护模块8，用于与Tracker服务器通过维护消息(如周期性保活信令)查询资源提供方的数据分片信息，对存储模块进行更新。

分组模块0，用于根据资源提供方信息确定当前所请求的数据分片的所有资源提供方数目n，将当前所请求的数据分片划分为不大于n的m个数据片；选择m个资源提供方，通过信令协商模块并发协商与m个资源提供方的数据传输。

图11为根据本发明资源调度装置实施例三的示意图，图11是对图10的细化，其中，可以单独增加查询模块10，用于从存储模块获取相应的资源提供方信息，并通过Tracker服务器查询所请求数据分片的资源提供方信息，从两组资源提供方信息中选择一至多个资源提供方协商数据传输。

图11还可以同时增加查询模块10及判断模块12，其中：

查询模块10，用于从本地的对应关系查询到当前请求的数据分片的资源提供方信息；在查询不到相应的资源提供方时，通过Tracker服务器查询当前请求的数据分片的资源提供方信息；

判断模块12，用于根据查询模块的资源提供方信息判断出请求数据分片保存在最近一次数据传输的资源提供方时从最近一次数据传输的资源提供方协商数据传输或者根据所有资源提供方数目n，将所请求的数据分片划分为不大于n的m个数据片，选择m个资源提供方并发协商数据传输。

图9-图11的资源调度装置可参见图2-图8的方法及***实施例中资源请求方的相关说明。

图12为根据本发明资源调度装置实施例四的示意图，图12所示的装置可以位于流媒体***的对等体Peer中，应用在资源提供方侧，具体可参见图2-图8的方法及***实施例中资源提供方的相关说明。如图12所示，包括：

接口模块1，用于接收当前数据分片的数据协商消息，返回当前数据分片的相关分片信息，如在资源请求方的当前数据分片会话请求对应的会话应答消息中携带相关分片信息；

查询模块3，用于根据当前数据分片信息查找相关分片信息；

存储模块5，用于存储各数据分片的数据内容，如图12所示，包括当前数据分片及相关分片。

图13为根据本发明资源调度装置实施例五的示意图，图13所示的装置主要应用与服务器一侧，可以位于P2P流媒体***中Tracker服务器内部，具体可参见图2-图8的方法及***实施例中Tracker服务器的相关说明。如图13，该装置包括：

接口模块11，用于接收资源请求方的当前数据分片请求，以及与资源提供方的数据协商信令；

存储模块15，用于存储数据分片对应的资源提供方信息；

查询模块13，用于根据资源请求方的当前数据分片请求，从存储模块查询当前数据分片的资源提供方信息，返回给资源请求方；

信令协商模块17，用于接收资源请求方的会话请求并发送至资源提供方，并将源提供方返回的所述相关分片信息发送至资源请求方。

图14为根据本发明资源调度装置实施例六的示意图。图14为对图13的细化，进一步包括：

监测模块19，用于监测信令协商模块的传输质量，在监测到资源请求方与资源提供方的传输质量低于预设条件时，向资源请求方发送当前数据分片的资源提供方信息和/或调整资源提供方的优先级，具体可参见图4实施例的优化资源调度方式。

监测模块19，还可以监测预设时间内未收到所述资源提供方的会话请求反馈信息时，向资源请求方发送通知消息。

还可以包括：判别模块21，用于当查询模块查找的资源提供方信息中的资源提供方数目小于预设值时，向媒体服务器发送包含资源请求方及当前所请求数据分片的资源调度请求，具体可参见图4实施例的优化资源调度方式二。

本发明还提供一种对等体，可以包括图9-图11任一项的资源调度装置，以及图12的资源调度装置，本领域技术应了解，在P2P***中，对等体在某时刻作为资源提供方，在另一时刻可作为资源请求方，也可以同时作为某一数据资源的资源提供方和另一数据资源的请求方，因此，可以同时具有图2-图8的方法及***实施例中请求方和提供方的相应功能，以实现高效的资源调度。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟、专用集成电路(ASIC)、数字信号处理器(DSP)、可编程逻辑装置(PLD)、现场可编程门阵列(FPGA)、处理器、控制器、微控制器、微处理器、电子装置、其它经设计以执行本文所描述的功能的电子单元或其组合内。

最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (36)

1.一种资源调度方法，其特征在于，包括：

资源请求方根据当前数据分片的资源提供方信息与至少一个资源提供方协商数据传输，接收资源提供方返回的所述当前数据分片的相关分片信息；

所述资源请求方保存所述相关分片信息与资源提供方的对应关系，在请求数据分片时从所述对应关系查询资源提供方信息。

2.根据权利要求1所述的资源调度方法，其特征在于，所述资源请求方根据当前数据分片的资源提供方信息与至少一个资源提供方协商数据传输包括：

所述资源请求方与资源提供方通过索引服务器转发数据协商信令。

3.根据权利要求2所述的资源调度方法，其特征在于，所述索引服务器转发数据协商信令的操作还包括：

所述索引服务器监测到预设时间内未收到所述资源提供方的反馈信息时，向所述资源请求方发送通知消息；

所述通知消息包括根据所述资源提供方的未反馈信息更新所述对应关系或删除所述资源提供方。

4.根据权利要求2所述的资源调度方法，其特征在于，所述索引服务器转发数据协商信令的操作还包括：

所述索引服务器监测到所述资源请求方对同一数据分片的多次请求或者预设时间内未收到所述资源请求方的会话请求对应的拆除连接信令时，向所述资源请求方返回当前数据分片的资源提供方信息和/或调整对应资源提供方的优先级。

5.根据权利要求1所述的资源调度方法，其特征在于，进一步包括：

资源请求方从所述对应关系未查询到所请求数据分片的资源提供方信息时，从索引服务器查询所请求数据分片的资源提供方信息。

6.根据权利要求1所述的资源调度方法，其特征在于，还包括：

资源请求方通过索引服务器或所述对应关系查询所请求数据分片的资源提供方信息；

当所述资源提供方信息的资源提供方数目据小于预设值时，所述索引服务器通知媒体服务器进行资源调度；

所述资源请求方通过所述媒体服务器获取所请求数据分片的资源提供方信息。

7.根据权利要求1所述的资源调度方法，其特征在于，所述资源请求方根据当前数据分片的资源提供方信息与至少一个资源提供方协商数据传输还包括：

所述资源请求方确定当前所请求数据分片的所有资源提供方数目n，将当前所请求的所述数据分片划分为不大于所述n的m个数据片，选择m个资源提供方并发协商数据传输。

8.根据权利要求1所述的资源调度方法，其特征在于，在进一步包括：

资源请求方根据所述对应关系查询所请求数据分片的资源提供方信息；

通过索引服务器查询所请求数据分片的资源提供方信息；

从上述资源提供方信息中选择一至多个资源提供方进行后续协商数据传输的操作。

9.根据权利要求1所述的资源调度方法，其特征在于，还包括：

所述资源请求方与索引服务器通过维护消息获取资源提供方的数据分片信息，对所述对应关系进行更新。

10.根据权利要求1所述的资源调度方法，其特征在于，资源请求方根据当前数据分片的资源提供方信息与至少一个资源提供方协商数据传输包括：

当前数据分片保存在最近一次数据传输的资源提供方内，则与所述最近一次数据传输的资源提供方协商数据传输；或者

根据资源提供方信息确定所有资源提供方数目n，将当前数据分片划分为不大于所述n的m个数据片，选择m个资源提供方并发协商数据传输。

11.根据权利要求1-10任一项所述的资源调度方法，其特征在于，所述资源请求方与所述资源提供方位于P2P流媒体***。

12.一种资源调度***，其特征在于，包括：

资源请求方，用于根据当前数据分片的资源提供方信息与至少一个资源提供方协商数据传输；接收资源提供方返回的所述当前数据分片的相关分片信息，保存所述相关分片信息与资源提供方的对应关系，在请求数据分片时从所述对应关系查询资源提供方信息；

资源提供方，用于与资源请求方协商数据传输，根据所述资源请求方的当前数据分片请求返回所述当前数据分片的相关分片信息。

13.根据权利要求12所述的资源调度***，其特征在于，还包括：

索引服务器，用于根据所述资源请求方的数据分片请求，返回资源提供方信息；接收所述资源请求方的会话请求发送至资源提供方，并将源提供方返回的所述相关分片信息发送至资源请求方。

14.根据权利要求12所述的资源调度***，其特征在于，所述索引服务器包括：

存储模块，用于存储数据分片对应的资源提供方信息；

查询模块，用于根据所述资源请求方的当前数据分片请求，从所述存储模块查询当前数据分片的资源提供方信息；

信令协商模块，用于接收所述资源请求方的会话请求发送至资源提供方，并将源提供方返回的所述相关分片信息发送至资源请求方；

监测模块，用于监测到所述资源请求方与所述资源提供方的传输质量低于预设条件时，向所述资源请求方发送当前数据分片的资源提供方信息和/或调整对应资源提供方的优先级。

15.根据权利要求12所述的资源调度***，其特征在于，所述索引服务器包括：判别模块，用于当所述资源提供方信息中的资源提供方数目小于预设值时，向媒体服务器发送包含所述资源请求方及当前数据分片的资源调度请求；

所述***还包括：媒体服务器，用于接收所述索引服务器的所述资源调度请求，向所述资源请求方返回当前数据分片的资源提供方信息。

16.根据权利要求12-15任一项所述的资源调度***，其特征在于，所述资源请求方包括：

获取模块，用于从所述索引服务器、媒体服务器或所述对应关系获取当前数据分片的资源提供方信息；

信令协商模块，用于根据所述资源提供方信息与至少一个资源提供方信令协商数据传输，接收资源提供方返回的所述当前数据分片的相关分片信息；

存储模块，用于保存当前数据分片的资源提供方信息，及所述相关分片与资源提供方的对应关系信息。

17.根据权利要求16所述的资源调度***，其特征在于，所述资源请求方还包括：

维护模块，用于与所述索引服务器通过维护消息获取资源提供方的数据分片信息，对所述存储模块进行更新。

18.根据权利要求16所述的资源调度***，其特征在于，所述资源请求方还包括：

分组模块，用于根据所述资源提供方信息确定当前数据分片的所有资源提供方数目n，将当前所请求的所述数据分片划分为不大于所述n的m个数据片；选择m个资源提供方并发协商数据传输；或者

判断模块，用于根据资源提供方信息判断出当前所请求数据分片保存在最近一次数据传输的资源提供方内时与所述最近一次数据传输的资源提供方协商数据传输或者根据所述分组模块并发协商数据传输。

19.根据权利要求16所述的资源调度***，其特征在于，所述资源请求方还包括：

查询模块，用于从所述存储模块获取请求的数据分片的资源提供方信息；从索引服务器查询所请求的数据分片的资源提供方信息，从所述两组资源提供方信息中选择一至多个资源提供方协商数据传输。

20.根据权利要求16所述的资源调度***，其特征在于，所述资源请求方还包括：

查询模块，用于从所述对应关系查询当前请求的数据分片的资源提供方信息；否则通过所述索引服务器查询资源提供方信息。

21.一种资源调度装置，其特征在于，包括：

信令协商模块，用于根据当前数据分片的资源提供方信息与至少一个资源提供方信令协商数据传输，接收资源提供方返回的所述当前数据分片的相关分片信息；

存储模块，用于保存当前数据分片的资源提供方信息，及所述相关分片与资源提供方的对应关系信息；

获取模块，用于从所述对应关系查询当前数据分片的资源提供方信息。

22.根据权利要求21所述的资源调度装置，其特征在于，位于P2P流媒体***的对等体Peer中。

23.根据权利要求21所述的资源调度装置，其特征在于，所述获取模块进一步从索引服务器或媒体服务器查询当前数据分片的资源提供方信息。

24.根据权利要求21所述的资源调度装置，其特征在于，还包括：

查询模块，用于从所述对应关系查询当前请求的数据分片的资源提供方信息；在未查询到时通过所述获取模块从所述索引服务器或媒体服务器查询资源提供方信息。

25.根据权利要求21所述的资源调度装置，其特征在于，还包括：

查询模块，用于从所述存储模块获取当前请求的数据分片的资源提供方信息，从索引服务器查询当前请求的数据分片的资源提供方信息，从所述两组资源提供方信息中选择一至多个资源提供方。

26.根据权利要求21所述的资源调度装置，其特征在于，还包括：

维护模块，用于与索引服务器通过维护消息查询资源提供方的数据分片信息，对所述存储模块进行更新。

27.根据权利要求21-26任一项所述的资源调度装置，其特征在于，还包括：

分组模块，用于根据所述资源提供方信息确定当前数据分片的所有资源提供方数目n，将当前所请求的所述数据分片划分为不大于所述n的m个数据片；选择m个资源提供方并发协商数据传输。

28.根据权利要求27所述的资源调度装置，其特征在于，还包括：

判断模块，用于根据资源提供方信息判断所请求数据分片保存在最近一次数据传输的资源提供方内时从所述最近一次数据传输的资源提供方协商数据传输或者根据所述分组模块并发协商数据传输。

29.一种资源调度装置，其特征在于，包括：

接口模块，用于接收当前数据分片的数据协商消息，返回所述当前数据分片的相关分片信息；

查询模块，用于根据所述当前数据分片信息查找所述相关分片信息；

存储模块，用于存储各数据分片的数据内容。

30.根据权利要求29所述的资源调度装置，其特征在于，位于P2P流媒体***的对等体Peer中。

31.根据权利要求29或30所述的资源调度装置，其特征在于，所述接口模块在所述当前数据分片请求的会话应答消息中携带所述相关分片信息。

32.一种资源调度装置，其特征在于，包括：

存储模块，用于存储数据分片对应的资源提供方信息；

查询模块，用于根据资源请求方的当前数据分片请求，从所述存储模块查询当前数据分片的资源提供方信息，返回所述资源请求方；

信令协商模块，用于接收所述资源请求方的会话请求并发送至资源提供方，并将源提供方返回的所述相关分片信息发送至所述资源请求方。

33.根据权利要求32所述的资源调度装置，其特征在于，位于P2P流媒体***的索引服务器内部。

34.根据权利要求32所述的资源调度装置，其特征在于，还包括：

监测模块，用于监测所述信令协商模块的传输质量，监测到所述资源请求方与所述资源提供方的传输质量低于预设条件时，向所述资源请求方发送当前数据分片的资源提供方信息和/或调整资源提供方的优先级。

35.根据权利要求32所述的资源调度装置，其特征在于，还包括：

监测模块，用于监测到预设时间内未收到所述资源提供方的会话请求反馈信息时，向所述资源请求方发送通知消息。

36.根据权利要求32、33、34或35所述的资源调度装置，其特征在于，还包括：

判别模块，用于当所述查询模块查找的资源提供方信息中的资源提供方数目据小于预设值时，向媒体服务器发送包含所述资源请求方及当前所请求数据分片的资源调度请求。

Images