一种P2P音乐点播系统的补偿方法转让专利
申请号 : CN200910063578.0
文献号 : CN101626400B
文献日 : 2012-03-28
发明人 : 程文青 , 喻丹 , 陈京文 , 吴砥
申请人 : 华中科技大学
摘要 :
本发明属于P2P网络流媒体技术领域，更具体地，涉及一种P2P音乐点播系统的补偿方法。本发明提供的音乐点播补偿机制包括：启动补偿，针对不能够立即启动播放音乐数据文件的情况进行补偿；播放时补偿，针对音乐播放已经启动的情形进行补偿。通过本发明提供的方案，可以减小音乐播放的启动时延、保证音乐播放连续性，并可提高系统可扩展性，从而缩短用户等待时间，改善用户体验。
权利要求 :
1.一种P2P音乐点播系统的补偿方法，所述P2P音乐点播系统中包括有音乐源服务器和节点，其特征是：在P2P音乐点播系统中设置目录服务器，音乐源服务器、目录服务器和节点基于集中式的非结构化拓扑实现网络连接；所述目录服务器用于掌控全网节点信息并提供资源节点定位，P2P音乐点播系统中传输和播放的音乐数据文件被划分为等长字节的数据块并从1开始依次编号，每个分块叫做1个chunk；
P2P音乐点播系统中的节点选择chunk并向拥有该chunk的其他节点请求下载；每个节点设置一个补偿空间，记为CA，用于存放该节点可能需要补偿的chunk编号；
根据节点启动播放音乐数据文件的情况，提供了启动补偿过程和播放补偿过程，所述启动补偿过程，用于针对播放启动和用户VCR操作之后尚未缓存所需数据块的情况，通过预先设定的概率pc从音乐源服务器请求播放时间靠前的chunk，以减少启动时延；
包括以下步骤，
步骤1.1，根据启动播放音乐数据文件需要缓存的连续chunk数目，确定需要补偿的chunk编号；
步骤1.2，将需要补偿的chunk编号放入该节点的补偿空间CA；
步骤1.3，如果从其他节点请求下载的chunk的编号不属于补偿空间CA，且补偿空间CA不为空，则以概率pc选择补偿空间CA中编号最小的chunk向音乐源服务器请求，并将此chunk编号从补偿空间CA中移除；
步骤1.4，若播放启动需要缓存的连续chunk都已完成下载，播放启动，启动补偿流程结束；
所述播放补偿过程，用于针对播放已经启动的情况，对来不及从其它节点下载的chunk从音乐源服务器请求，以保证播放连续性；包括以下步骤，步骤2.1，根据历史下载chunk所需的时间，预估从其他节点下载一个chunk所需的时间；
步骤2.2，根据步骤2.1预估的时间判定当前播放位置后需要补偿的chunk；
步骤2.3，将需要补偿的chunk编号放入补偿空间CA；
步骤2.4，将补偿空间CA中所有对应编号的chunk向音乐源服务器请求，然后清空补偿空间CA；
步骤2.5，当前播放位置内容播放完成后，返回步骤2.2针对新的当前播放位置进行补偿，直到整个音乐数据文件播放完成。
2.如权利要求1所述的P2P音乐点播系统的补偿方法，其特征是：所述P2P音乐点播系统中的节点选择chunk并向拥有该chunk的其他节点请求下载，实现方式为节点周期性利用chunk选择算法选择chunk并向拥有该chunk的节点请求，所述chunk选择算法基于顺序优先和稀有优先策略，并给以顺序优先较高优先权。
3.如权利要求1或2所述的P2P音乐点播系统的补偿方法，其特征是：所述chunk的状态分为“未请求”、“从节点下载中”、“从服务器下载中”和“已下载”四种，当某chunk下载超时，重新设定该chunk状态为“未请求”。
4.如权利要求1或2所述的P2P音乐点播系统的补偿方法，其特征是：所述播放补偿过程中的chunk下载时间预估，实现方法为根据节点已下载的每个chunk的从请求到接收E的时间差，求取离散值；根据下载情况触发预估时间Tra 在离散值之间的动态调整，且离散值被周期性或触发式更新。
说明书 :
一种P2P音乐点播系统的补偿方法
技术领域
[0001] 本发明涉及P2P(Peer-to-Peer，对等)网络流媒体技术领域，更具体地，涉及一种P2P音乐点播系统的补偿方法。
背景技术
[0002] 音乐点播应用越来越普及，但高质量音乐对带宽资源要求较高，传统C/S模式不能满足应用需求，服务器很容易成为系统瓶颈；IP组播通过中间节点(peer)分布式并发传输音频流的方式减轻服务器和网络负载，但由于部署原因，很难在Internet上广泛实施；CDN采用代理缓存节点的方式将服务和内容推向网络“边缘”，但部署昂贵且存在与C/S模式类似的瓶颈；P2P流媒体通过利用普通节点的资源为其它节点提供服务，在不改变现有网络配置的前提下具有良好的性价比，是一种具有广泛应用前景的音频分发方法。
[0003] 在基于P2P网络的音乐点播系统中，音乐源服务器是一个必不可少的部分，它提供音乐源数据的分发。每个节点不仅可以从其它节点获取数据(大部分来自于此)，还会以一定方式从音乐源服务器获取数据，以保证较小启动时延和播放连续性。把从音乐源服务器获取数据的方式叫做“补偿”。
[0004] 现有P2P音乐点播系统中，主要采取一些简单的方式从音乐源服务器获取音频数据，如在播放启动后，每当播放一音乐数据块时检查当前播放位置后一段固定时间长度(如10s)的数据，如尚未完成下载，则直接从音乐源服务器获取数据。这样的策略在一定程度上有益于播放连续性的提高，但存在一些严重的不足，主要是：
[0005] 1)没有考虑减小启动时延的补偿策略。由于系统采取P2P模式，有可能先下载到播放时间较后的音乐数据，而前面的音乐数据迟迟不能得到下载，因而增大了启动时延；
[0006] 2)没有确定哪些数据真正需要补偿。有可能造成数据过多或过少补偿，过多补偿会增大服务器压力，使音乐源服务器成为系统瓶颈，影响系统可扩展性；过少补偿引起播放连续性能下降，经常出现停滞，影响用户体验。
[0007] 针对以上不足，有必要提出一种P2P音乐点播系统的补偿机制，以减小启动时延和音乐源服务器压力并保证播放连续性。
发明内容
[0008] 为了解决P2P音乐点播系统中存在的启动时延问题、播放连续性问题和系统可扩展性问题，实现更好的音乐在线服务质量，本发明提出一种新的补偿方法。
[0009] 本发明提供的技术方案为P2P音乐点播系统的补偿方法一种P2P音乐点播系统的补偿方法，所述P2P音乐点播系统中包括有音乐源服务器和节点，在P2P音乐点播系统中设置目录服务器，音乐源服务器、目录服务器和节点基于集中式的非结构化拓扑实现网络连接；所述目录服务器用于掌控全网节点信息并提供资源节点定位，
[0010] P2P音乐点播系统中传输和播放的音乐数据文件被划分为等长字节的数据块并依次从1编号，每个分块叫做1个chunk；
[0011] P2P音乐点播系统中的节点选择chunk并向拥有该chunk的其他节点请求下载；每个节点设置一个补偿空间，记为CA，用于存放该节点可能需要补偿的chunk编号；
[0012] 根据节点启动播放音乐数据文件的情况，提供了启动补偿过程和播放补偿过程，[0013] 所述启动补偿过程，用于针对播放启动和用户VCR操作之后尚未缓存所需数据块的情况，通过预先设定的概率pc从音乐源服务器请求播放时间靠前的chunk，以减少启动时延；包括以下步骤，
[0014] 步骤1.1，根据启动播放音乐数据文件需要缓存的连续chunk数目，确定需要补偿的chunk编号；
[0015] 步骤1.2，将需要补偿的chunk编号放入该节点的补偿空间CA；
[0016] 步骤1.3，如果从其他节点请求下载的chunk的编号不属于补偿空间CA，且补偿空间CA不为空，则以概率pc选择补偿空间CA中编号最小的chunk向音乐源服务器请求，并将此chunk编号从补偿空间CA中移除；
[0017] 步骤1.4，若播放启动需要缓存的连续chunk都已完成下载，播放启动，启动补偿流程结束；
[0018] 所述播放补偿过程，用于针对播放已经启动的情况，对来不及从其它节点下载的chunk从音乐源服务器请求，以保证播放连续性；包括以下步骤，
[0019] 步骤2.1，根据历史下载chunk所需的时间，预估从其他节点下载一个chunk所需的时间；
[0020] 步骤2.2，根据步骤2.1预估的时间判定当前播放位置后需要补偿的chunk；
[0021] 步骤2.3，将需要补偿的chunk编号放入补偿空间CA；
[0022] 步骤2.4，将补偿空间CA中所有对应编号的chunk向音乐源服务器请求，然后清空补偿空间CA；
[0023] 步骤2.5，当前播放位置内容播放完成后，返回步骤2.2针对新的当前播放位置进行补偿，直到整个音乐数据文件播放完成。
[0024] 而且，所述P2P音乐点播系统中的节点选择chunk并向拥有该chunk的其他节点请求下载，实现方式为节点周期性利用chunk选择算法选择chunk并向拥有该chunk的节点请求，所述chunk选择算法基于顺序优先和稀有优先策略，并给以顺序优先较高优先权。
[0025] 而且，所述chunk的状态分为“未请求”、“从节点下载中”、“从服务器下载中”和“已下载”四种，当某chunk下载超时，重新设定该chunk状态为“未请求”。
[0026] 而且，所述播放补偿过程中的chunk下载时间预估，实现方法为根据节点已下载E的每块chunk的从请求到接收的时间差，求取离散值；预估时间Tra 根据下载情况触发其在离散值之间动态调整，且离散值被周期性或触发式更新。
[0027] 本发明提供的音乐点播补偿机制包括有：启动补偿，针对用户刚加入系统或进行了VCR操作的情形进行补偿；播放时补偿，针对音乐播放已经启动的情形进行补偿。通过本发明提供的方案，可以减小音乐播放的启动时延、保证音乐播放连续性，并可提高系统可扩展性，从而缩短用户等待时间，改善用户体验。
附图说明
[0028] 图1为本发明的P2P音乐点播系统总体架构；
[0029] 图2为本发明的节点缓存结构；
[0030] 图3为本发明实施例的TraE(chunk的请求到达预估时间)状态转移图。
具体实施方式
[0031] 以下结合附图和实施例对本发明进行详细的描述。
[0032] 如图1所示，本发明的P2P音乐点播系统主要由基于集中式的非结构化拓扑实现网络连接的音乐源服务器、目录服务器和普通节点(如peer1、peer2、peer3、peer4、peer5、peer6)组成，可由Internet实现网络互联。其中音乐源服务器负责原始音乐数据文件的存储和分发；目录服务器负责管控所有参与节点信息，包括每个节点的加入时间、播放位置、负载等情况，并帮助节点进行资源节点的定位，普通节点从加入音乐点播系统开始即周期性地与目录服务器交互，使得目录服务器能够及时更新用户信息。普通节点一般是普通音乐欣赏用户的个人主机，负责资源请求并为其他用户提供下载服务，同时提供友好的用户接口，通过接入Internet可以方便地实现进入P2P音乐点播系统，网内在线节点可以实现节点交互。本发明采用集中式管理方案，即设置目录服务器维护所有参与节点的信息，根据此全网节点信息进行资源节点定位，即返回给用户最优的提供音乐数据资源的伙伴节点列表，其优点是能够快速响应定位，可以针对全网音乐传输进行优化处理，使得整个P2P音乐点播系统具有高度的可控性。而现有技术采用的分布式方案由于节点信息维护的分散，不适合集中管控和全网优化，同时也增大了响应等待时间。本发明采用非结构化模式进行音频内容的分发，即节点根据目录服务器返回的伙伴列表，自组织成为无固定拓扑结构的应用层覆盖网络，每个节点可以为多个其他节点提供音乐数据，同时也可以从多个伙伴节点下载所需的数据，降低了节点动态性产生的影响。而对于结构化模式下的数据传输，由于需要维护一个应用层的链式或树状结构，其维护开销大且无法解决节点的高动态性问题。
[0033] 本发明将音乐数据源文件切分为等长的块且从1开始顺序编号，划分得到的每个数据分块记为1个chunk，是传输和播放的数据单位。节点采用滑动窗口机制来缓存和播放音乐chunk。如图2所示，为了减少音频数据离散造成的影响，节点不仅可以缓存最接近当前播放位置的音乐数据，也可以预先下载缓存其余的次接近播放位置的音乐数据，以便为其它节点提供服务，减少稀有资源和离散资源对音乐点播系统的影响。实施例中，节点请求数据与播放使用同一缓存，分为两个部分，高优先级缓存和低优先级缓存，分别以符号BH、BL表示。BH缓存最接近播放位置的音乐数据，BL缓存剩下的次接近播放位置的部分音乐数据。BH的长度为lH，BL的长度为lL，整个缓存长度为lB，则lH+lL＝lB。BH和BL均为定长缓存，lH与lL的比值范围建议取1/6～1/2。设B(n)为节点缓存中第n块存储区，从1开始编号，则BH的缓存空间范围是B(1)、B(2)、......、B(lH)，BL的缓存空间范围是B(lH+1)、B(lH+2)、......、B(lB)。若某时刻当前播放位置为音乐数据文件的第m号chunk，此时缓存与音频数据文件各个chunk的对应关系如图2所示，BH缓存空间内的B(1)、B(2)、......、B(lH)依次存放第m、m+1、......、m+lH-1号chunk，BL缓存空间内的B(lH+1)、B(lH+2)、......、B(lB)依次存放第m+lH、m+lH+1、......、m+lB-1号chunk。缓存空间对应的chunk选择窗口WH和WL随着音乐播放向右滑动。播放后的chuck存放在节点主机的本地磁盘中，以便为其它节点提供音乐传输服务。
[0034] 为了便于标明节点中的chunk下载情况，将chunk的状态分为“Unrequested(未请求)”、“DownloadingFromPeer(从节点下载中)”、“DownloadingFromServer(从服务器下载中)”和“Downloaded(已下载)”四种。“Unrequested(未请求)”表示尚未从其他节点或音乐源服务器请求下载；若下载超时，则可自动重新设定状态为“Unrequested”。“DownloadingFromPeer(从节点下载中)”表示已经向其他拥有该chuck的节点请求，处于下载过程中。“DownloadingFromServer(从服务器下载中)”表示已经向音乐源服务器请求，处于下载过程中。“Downloaded(已下载)”表示已经从其他节点或音乐源服务器下载完该chuck，或者节点本地预先存有该chuck无需请求下载。
[0035] 节点选择chunk并向拥有该chunk的其他节点请求下载节点，可有多种实现方式。本发明提出实现方式为节点周期性利用chunk选择算法选择chunk并向拥有该chunk的节点请求，所述chunk选择算法基于顺序优先和稀有优先策略，并给以顺序优先较高优先权。
为了便于说明节点拥有的chuck资源，节点使用位图(BitMap)信息来表征自己拥有音乐数据文件分块的状态，“1”表示某chunk存4在，“0”表示某chunk不存在。因为节点往往是根据用户需要，动态加入P2P音乐点播系统的，节点加入系统后，首先向目录服务器请求资源节点，然后周期性利用chunk选择算法选择chunk向资源节点请求下载；同时对于需要补偿的chunk，通过服务器补偿。具体方式为，节点根据目录服务器返回的资源节点列表周期性的向其请求位图信息，根据此位图信息选择合适的chunk进行下载，chunk选择算法为：
根据资源节点的BitMap信息，以预先设定的概率pcs在WH内以顺序优先算法选择尚未请求的chunk并返回编号，以概率1-pcs在WL内以稀有优先算法选择尚未请求的chunk并返回编号；当没有选择到可以下载的chunk时，返回的chunk编号为0。具体顺序优先算法为在WH内按照chunk编号依次选择编号较小的未请求chunk进行请求，稀有优先算法为在WL内选择所有资源节点中拥有数量最少的未请求chunk进行请求。本领域技术人员可以根据具体需要采用软件方式实现顺序优先算法和稀有优先算法，本发明不予赘述。概率pcs建议取值范围为0.6～0.9，使得顺序优先选择算法有较高的优先级。
为了便于说明节点拥有的chuck资源，节点使用位图(BitMap)信息来表征自己拥有音乐数据文件分块的状态，“1”表示某chunk存4在，“0”表示某chunk不存在。因为节点往往是根据用户需要，动态加入P2P音乐点播系统的，节点加入系统后，首先向目录服务器请求资源节点，然后周期性利用chunk选择算法选择chunk向资源节点请求下载；同时对于需要补偿的chunk，通过服务器补偿。具体方式为，节点根据目录服务器返回的资源节点列表周期性的向其请求位图信息，根据此位图信息选择合适的chunk进行下载，chunk选择算法为：
根据资源节点的BitMap信息，以预先设定的概率pcs在WH内以顺序优先算法选择尚未请求的chunk并返回编号，以概率1-pcs在WL内以稀有优先算法选择尚未请求的chunk并返回编号；当没有选择到可以下载的chunk时，返回的chunk编号为0。具体顺序优先算法为在WH内按照chunk编号依次选择编号较小的未请求chunk进行请求，稀有优先算法为在WL内选择所有资源节点中拥有数量最少的未请求chunk进行请求。本领域技术人员可以根据具体需要采用软件方式实现顺序优先算法和稀有优先算法，本发明不予赘述。概率pcs建议取值范围为0.6～0.9，使得顺序优先选择算法有较高的优先级。
[0036] 节点刚加入P2P音乐点播系统或进行了VCR操作(用户执行的拖动操作)后，往往需要在缓存了当前播放位置后一段连续的音乐数据后，启动播放，然后一边下载一边播放。从开始点播到完成播放的整个过程中，需要使用补偿机制保障低启动延时、高播放连续性和低服务器压力，并提高P2P音乐点播系统的可扩展性。为了进行及时有效的补偿，每个节点设置一个补偿空间，记为CA，用于存放该节点可能需要补偿的chunk编号。实现补偿时，可以使用一定的补偿策略选择集合CA中的chunk向音乐源服务器请求下载。本发明采用的补偿策略是，根据节点启动播放音乐数据文件的情况，分别提供了启动补偿过程和播放补偿过程。
[0037] 启动补偿是针对不能够立即启动播放音乐数据文件的情况(一般是节点刚加入系统或进行了VCR操作)，目的是减小启动时延，缩短用户等待时间。实现策略为通过预先设定的概率Pc从音乐源服务器请求播放时间靠前的chunk。记播放启动所需缓存当前播放位置后连续chunk的数目为N，则节点播放启动的条件是缓存空间B(1)、B(2)、......、B(N)为满。若B(1)(也即当前播放位置)对应的chunk编号为m，具体实现过程步骤如下：
[0038] 步骤1.1，根据启动播放音乐数据文件需要缓存的连续chunk数目，确定需要补偿的chunk编号；
[0039] 实施例是将chunk编号为m，m+1，......，m+N-1且处于状态“Unrequested(未请求)”的编号添加到补偿空间CA中。若某时刻chunk编号为a∈[m，m+N-1]的chunk下载超时，重新添加到CA中。
[0040] 步骤1.2，将需要补偿的chunk编号放入该节点的补偿空间CA；
[0041] 步骤1.3，如果从其他节点请求下载的chunk的编号不属于补偿空间CA，且补偿空间CA不为空，则以概率pc选择补偿空间CA中编号最小的chunk向音乐源服务器请求，并将此chunk编号从补偿空间CA中移除；
[0042] 实施例中，为了避免同一个chunk从资源节点下载和从服务器补偿发生冲突，记当前根据chunk选择算法选择的chunk号为d，没有选择到可以下载的chunk时，返回的chunk编号d为0。如果d不为0，向资源节点请求下载该chunk。若d∈CA，则因为已经从选择节点下载，将此chunk从CA中移出。否则，如果d不属于补偿空间CA，且补偿空间CA不为空，则可以概率pc选择CA内编号最小的chunk，向音乐源服务器请求下载，并将此chunk编号补偿空间CA中移除。本发明建议，当d为0时，pc＝1；d不为0时，建议pc的取值范围为0.5～0.7。步骤1.4，若播放启动需要缓存的连续chunk都已完成下载，播放启动，启动补偿流程结束；若播放启动需要缓存的连续chunk尚未全部完成下载，
[0043] 实施例中，缓存了当前播放位置后连续的N个chunk后，播放启动，启动补偿流程结束。
[0044] 所述播放补偿过程，用于针对播放已经启动的情况，对来不及从其它节点下载的chunk从音乐源服务器请求，以保证播放连续性。为了获得良好的播放连续性能，需要相关chunk在播放截止时间前完成下载，以避免播放时停滞；同时，不能过多地从音乐源服务器下载，以保持服务器压力不至于过大，提高系统可扩展性能。本发明提供具体实现过程步骤如下：
[0045] 步骤2.1，根据历史下载chunk所需的时间，预估从其他节点下载一个chunk所需的时间；
[0046] 步骤2.2，根据步骤2.1预估的时间判定当前播放位置后需要补偿的chunk；
[0047] 步骤2.3，将需要补偿的chunk编号放入补偿空间CA；
[0048] 步骤2.4，将补偿空间CA中所有对应编号的chunk向音乐源服务器请求，然后清空补偿空间CA；
[0049] 步骤2.5，当前播放位置内容播放完成后，返回步骤2.2针对新的当前播放位置进行补偿，直到整个音乐数据文件播放完成。
[0050] 实施例中，设历史下载的z号chunk，其请求时刻tr(z)，收到时刻ta(z)，则z号chunk的请求到达时间差为Tra(z)＝ta(z)-tr(z)。预估从其他节点下载一个chunk所需的E时间，设结构为预估chunk请求到达时间差Tra，设当前播放位置为m号chunk，若m+k(k＝
1，2，3，......)号chunk尚未请求，则播放到m+k号chunk会出现停滞的条件是：
1，2，3，......)号chunk尚未请求，则播放到m+k号chunk会出现停滞的条件是：
[0051] TraE＞k*b/r (式1)
[0052] 其中，b为chunk的数据块大小，r为播放码率，b和r均为定值。预估chunk请求到达时间差大于播放截止时间时，可能在播放前不能从资源节点收到此chunk。因此，节点从音乐源服务器请求下载这些chunk，以减少或避免停滞。设当前播放位置对应的chunk编号为m，补偿策略如下：
[0053] 1)将 满 足 条 件( 式 1) 且 处 于 状 态“Unrequested( 未 请 求)” 或“DownloadingFromPeer(从节点下载中)”的chunk编号添加到补偿空间CA中；
[0054] 2)把补偿空间CA内所有的chunk向音乐源服务器请求下载，然后清空补偿空间CA。特殊的是，从音乐源服务器下载过程中，若补偿空间CA中的某个chunk从资源节点完成下载，则通知音乐源服务器取消该chunk的下载；
[0055] 3)当前播放位置内容播放完成后，返回1)进行持续补偿，直到整个音乐数据文件播放完成。
[0056] 要进行以上补偿策略，需要对(式1)中的TraE值进行确定。由于无法对TraE进行精确的估计，故实施例采取根据已经下载chunk的请求到达时间进行离散值估计并在播放过程中动态调整的方式进行确定。具体确定方式如下：
[0057] 记已经下载的chunk数为D，Tra(z)中的z取1～D，则TraE可取的离散值为：均值：
[0058] 最小值：Tmin＝min{Tra(1)，Tra(2)，…，Tra(D)}
[0059] 最大值：Tmax＝max{Tra(1)，Tra(2)，…，Tra(D）}
[0060] 定义集合L＝{Tm(z)|Tra(z)＜TM}，集合H＝{Tm(z)|Tra(z)≥TM}；设集合L的大小为l，集合H的大小为h，l+h＝D，则
[0061] 集合L的均值：
[0062] 集合H的均值：
[0063] 以上所得Tmin，TL，TM，TH和Tmax就是TraE可取的5个离散值，且这5个离散值和TraEE的取值都可在播放时动态调整。设Tra 调整周期为Tu，Tu内播放停滞总数为C，记Tu内向音乐源服务器请求且请求前处于状态“DownloadingFromPeer(从节点下载中)”的chunk总E
数为X，这些chunk能及时从其它节点完成下载的总数为x，以下定义触发Tra 动态调整的事件：
数为X，这些chunk能及时从其它节点完成下载的总数为x，以下定义触发Tra 动态调整的事件：
[0064] ①Tu时间到，C＞Co；
[0065] ②Tu时间到，C＜＝Co且x/X＞ρ；
[0066] ③Tu时间到，C＜＝Co且x/X＜＝ρ。
[0067] 其中，Tu建议取值30b/r～50b/r，Co建议取值3～5，ρ建议取值0.7～0.8。E
事件①表示由于预先进行了补偿，如果在一段时间内出现多次播放停滞现象，说明Tra 取值过小，需要补偿的chunk不满足条件(式1)，未能添加到CA中，因而不能及时补偿，此E
时应该增大Tra ；事件②表示如果在一段时间内向音乐源服务器请求且请求前处于状态“DownloadingFromPeer(从节点下载中)”的chunk能及时从其它节点获得的比例较大，且E E
无停滞或停滞次数较小，说明Tra 取值过大，补偿过度，此时应该减小Tra ；事件③表示当停E
滞次数和及时获得比例都较小时，Tra 保持不变。
事件①表示由于预先进行了补偿，如果在一段时间内出现多次播放停滞现象，说明Tra 取值过小，需要补偿的chunk不满足条件(式1)，未能添加到CA中，因而不能及时补偿，此E
时应该增大Tra ；事件②表示如果在一段时间内向音乐源服务器请求且请求前处于状态“DownloadingFromPeer(从节点下载中)”的chunk能及时从其它节点获得的比例较大，且E E
无停滞或停滞次数较小，说明Tra 取值过大，补偿过度，此时应该减小Tra ；事件③表示当停E
滞次数和及时获得比例都较小时，Tra 保持不变。
[0068] 为了使预估的TraE更为准确，可以更新离散值，即重新计算Tmin，TL，TM，TH和Tmax。离散值更新可采用周期性更新和触发式更新两种方式：
[0069] a)预先设定更新周期Tc(建议取4Tu～6Tu)，每当Tc时间到时，重新计算离散值，即周期性更新。
[0070] b)如图3所示，当满足以下条件之一时，立即重新计算离散值，即触发式更新：
[0071] 1)TraE＝Tmax且发生所述事件①；
[0072] 2)TraE＝Tmin且发生所述事件②；
[0073] 从条件可以看出，当TraE为当前最大离散值且仍需增大或TraE为当前最小离散值且仍需减小时，引起离散值触发式更新。
[0074] 因为求取所得tmin，TL，TM，TH和Tmax是由小到大，总结上述调整方案，实施例的TraEE动态调整的状态转移如图3所示：当Tra ＝Tmax时，发生事件①则触发五个离散值的更新，发E E E E
生事件②则Tra ＝TH；当Tra ＝TH时，发生事件①则Tra ＝Tmax，发生事件②则Tra ＝TM；当E E E E
Tra ＝TM时，发生事件①则Tra ＝TH，发生事件②则Tra ＝TL；当Tra ＝TL时，发生事件①则E E E E
Tra ＝TM，发生事件②则Tra ＝Tmin；当Tra ＝Tmin时，发生事件①则Tra ＝TL，发生事件②则E E
触发五个离散值的更新。Tra 为任意值时，若发生事件③Tra 则保存不变。
生事件②则Tra ＝TH；当Tra ＝TH时，发生事件①则Tra ＝Tmax，发生事件②则Tra ＝TM；当E E E E
Tra ＝TM时，发生事件①则Tra ＝TH，发生事件②则Tra ＝TL；当Tra ＝TL时，发生事件①则E E E E
Tra ＝TM，发生事件②则Tra ＝Tmin；当Tra ＝Tmin时，发生事件①则Tra ＝TL，发生事件②则E E
触发五个离散值的更新。Tra 为任意值时，若发生事件③Tra 则保存不变。
[0075] 播放补偿过程刚启动时或离散值更新后，需要设置TraE的初值，以根据(式1)确定需要补偿的chunk，并进入动态调整流程，设定方式分别如下：
[0076] 节点刚加入系统或VCR操作后，缓存了一定长度的音频数据，音乐播放启动，此时E播放补偿过程启动，为保证连续性初始化Tra ＝Tmax；
[0077] 离散值更新后，设定TraE为同等级的新离散值。例如：如果更新前TraE＝Tmax，记离E散值更新后新的最大值为Tmax(new)，则离散值更新后，初始化Tra ＝Tmax(new)。