CN101697553A - P2p环境下的数据传输方法 - Google Patents

P2p环境下的数据传输方法 Download PDF

Info

Publication number
CN101697553A
CN101697553A CN200910235678.7A CN200910235678A CN101697553A CN 101697553 A CN101697553 A CN 101697553A CN 200910235678 A CN200910235678 A CN 200910235678A CN 101697553 A CN101697553 A CN 101697553A
Authority
CN
China
Prior art keywords
data
neighbor node
node
data flow
user node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN200910235678.7A
Other languages
English (en)
Other versions
CN101697553B (zh
Inventor
王雷
叶靖
吕建明
林思明
李静远
刘悦
程学旗
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Institute of Computing Technology of CAS
Original Assignee
Institute of Computing Technology of CAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Institute of Computing Technology of CAS filed Critical Institute of Computing Technology of CAS
Priority to CN200910235678.7A priority Critical patent/CN101697553B/zh
Publication of CN101697553A publication Critical patent/CN101697553A/zh
Application granted granted Critical
Publication of CN101697553B publication Critical patent/CN101697553B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)

Abstract

本发明提供一种P2P环境下的数据传输方法,包括:对所要传输数据做分割后得到多组子数据流;在用户所登录的用户节点以及该用户节点的邻居节点上维护推送记录表,所述推送记录表用于记录所在节点所要推送以及所要接收的子数据流的信息;所述邻居节点按照随机的顺序将不同组的子数据流推送给所述用户节点,所述用户节点接收子数据流后结合所述推送记录表中的信息为所述邻居节点分配该邻居节点负责推送的子数据流;所述用户节点接收并保存所述邻居节点所推送的数据。本发明将推策略与拉策略相结合,能够尽可能地减少数据分片丢失情况的出现。本发明通过竞争机制实现子数据流的分配,能够减少冗余数据包的传输,提高整个系统的性能。

Description

P2P环境下的数据传输方法
技术领域
本发明涉及流媒体数据传输方法,特别涉及P2P环境下的数据传输方法。
背景技术
随着互联网络及其接入技术的快速发展,网络的数据传输能力得到了快速提升,这使得过去无法大面积应用的海量数据交互应用程序获得了极大的发展空间。此类的应用程序包括视频直播系统、视频点播系统、多媒体视像会议、远程医疗等。由于数据量过大,传统的客户端/服务器模式并不能满足这些应用程序,其服务器端有限的资源会被轻易占满,使得系统难以大面积部署。因此当前这些程序通常转而选择P2P互助的模式传输数据,以期快速、高效、廉价的部署到互联网络中。
相较于客户端/服务器模式,P2P技术拥有网络负载均衡、易于快速大规模部署的优点。以P2P视频直播系统为例,系统中各个客户端不但可以从视频的直接发布者请求数据,同时还可以从其它客户端中分享数据。这种分享策略虽然会在一定程度上造成视频播放的延迟,但却可以极大减轻该流媒体发布者的负担。实际上,对于普通的网络视频直播服务来说,用户只要能够流畅收看到所希望看到的直播节目就会有很高的用户满意度,而并不会在意数秒甚至数分钟的延迟。
虽然P2P的理念已经广泛应用于各种数据传输系统中,但是在实现细节方面,仍然有很多值得深入探讨和研究的问题:
第一,常见的网络终端接入技术,如ADSL等,大都存在下载能力大于上传能力的问题,由于P2P流媒体系统的终端互助特性使得一个P2P流媒体终端通常需要连接多个邻居节点才可以获得稳定的数据回放效果。如何打散媒体数据流、并将子数据流指派给邻居节点集合,才能使得P2P流媒体系统的主要性能指标最大化,当前还没有明确方案。
第二,P2P流媒体系统中数据交换包含两种基本策略:以数据提供节点为驱动力量的推策略和以数据获得节点为驱动力量的拉策略。
(1)推策略指P2P流媒体系统中的数据提供节点在未收到数据请求时,主动推送流媒体数据到其邻居节点。使用推策略可以降低系统客户端的网络时延,提高用户体验评分;但盲目使用推策略会导致数据的重复发送,对带宽资源会造成较大浪费;
(2)拉策略指P2P流媒体系统中数据请求节点显式发出媒体数据请求消息到其邻居节点,邻居节点处理该请求消息后决定是否发送媒体数据给该数据请求节点。使用拉策略可以最大限度地减小数据传输所占用的带宽资源;然而,该策略会在一定程度上牺牲网络的实时性。
发明内容
本发明的一个目的是克服现有技术将媒体数据流打散成子数据流时不能使P2P流媒体系统的主要性能指标最大化的缺陷,从而提供一种能够提高性能指标的P2P环境下的数据传输方法。
本发明的又一个目的是克服现有技术缺乏将推策略和拉策略相结合的数据交换方法的缺陷,从而提供一种能够将推策略和拉策略相结合的P2P环境下的数据传输方法。
为了实现上述目的,本发明提供了一种P2P环境下的数据传输方法,包括:
步骤1)、对所要传输数据做分割后得到多组子数据流;
步骤2)、在用户所登录的用户节点以及该用户节点的邻居节点上维护推送记录表,所述推送记录表用于记录所在节点所要推送以及所要接收的子数据流的信息;
步骤3)、所述邻居节点按照随机的顺序将不同组的子数据流推送给所述用户节点,所述用户节点接收子数据流后结合所述推送记录表中的信息为所述邻居节点分配该邻居节点负责推送的子数据流;
步骤4)、所述用户节点接收并保存所述邻居节点所推送的数据。
上述技术方案中,还包括:
步骤5)、所述用户节点在某些数据无法及时到达时,向除了负责该数据推送的邻居节点外的其它邻居节点请求该数据。
上述技术方案中,在所述的步骤1)中,对所要传输数据做分割包括分片、分组;其中,
所述分片包括将数据按照规定的格式大小分割,得到数据分片;所述分组包括将所述数据分片按照所述数据分配的标识进行分配,同一组的数据分片形成子数据流。
上述技术方案中,在对数据分片进行分组时,对所述数据分片的标识做取模操作,将标识取模后所得到的余数相同的数据分片分在同一组中。
上述技术方案中,所述步骤3)包括:
步骤3-1)、各个邻居节点对所述子数据流的序号做随机排列;
步骤3-2)、所述邻居节点根据随机排列结果将相应序号的子数据流按序推送给用户节点;
步骤3-3)、所述用户节点接收到某一邻居节点所推送的某一组子数据流后,根据自身的推送记录表的信息,决定是否将该子数据流分配给该邻居节点,并将决定后的结果通知该邻居节点。
上述技术方案中,所述步骤3-3)包括:
步骤3-3-1)、所述用户节点接收到某一邻居节点所推送的某一组子数据流后,若自身的推送记录表中记录拒绝接收该邻居节点所推送的该组子数据流,则向该邻居节点发送拒绝消息,该邻居节点接收到拒绝消息后,在其自身的推送记录表中记录,否则,执行下一步;
步骤3-3-2)、若用户节点自身的推送记录表中记录接收该邻居节点所推送的该组子数据流,则在该推送记录表中记录不接收其它邻居节点所推送的该组子数据流,并向该邻居节点发送接收消息,该邻居节点接收到接收消息后,在其自身的推送记录表中记录。
上述技术方案中,所述的步骤5)包括:
步骤5-1)、为数据设立未到达预警时刻;
步骤5-2)、在当前时刻到达该未到达预警时刻时,检查对应的数据是否已经到达了所述用户节点,若没有到达,则向除了负责该数据推送的邻居节点外的其它邻居节点请求该数据,否则不做操作;
步骤5-3)、所述邻居节点收到请求后,检查自身是否保存有相应的数据,若有,将该数据发送给所述用户节点,否则忽略该请求。
上述技术方案中,所述的步骤5)还包括:
步骤5-4)、若当前时刻大于最晚到达时刻时,所请求的数据还未到达所述用户节点,则抛弃该数据。
本发明的优点在于:
1、本发明将推策略与拉策略相结合,能够尽可能地减少数据分片丢失情况的出现。
2、本发明通过竞争机制实现子数据流的分配,能够减少冗余数据包的传输,提高整个系统的性能。
附图说明
图1为P2P直播系统的示意图;
图2为本发明的P2P环境下的数据传输方法的流程图;
图3为本发明的P2P环境下的数据传输方法中为邻居节点分配子数据流的流程图;
图4为本发明的P2P环境下的数据传输方法中用户节点主动请求数据分片的实现过程的流程图;
图5为对数据流的数据分片进行分组的示意图;
图6为本发明中所涉及的推送记录表的示意图;
图7为当前时刻、预警时刻、最晚到达时刻间关系的示意图。
具体实施方式
下面结合附图和具体实施方式对本发明进行说明。
在下面的实施例中以P2P环境为例,对本发明的方法进行说明。在说明方法之前,首先就P2P环境做一举例说明。
图1示出了一个P2P直播系统的示意图,P2P直播系统是一种典型的P2P应用环境。在该系统中包括有服务器和客户端节点,而客户端节点又可以分为直播发布者和直播观看者。上述的服务器和直播发布者参与某一直播数据的发布,而直播观看者则参与该直播数据的接收。由于直播发布者作为客户端节点本身参与流媒体数据的分发,因而能够极大减轻流媒体服务器端的工作压力,促进网络负载均衡,提高网络资源的使用效率。需要说明的是,图1所示P2P直播系统中的直播发布者与直播观看者的角色并不固定,对于某一客户端节点而言,它对于某一直播数据可能是发布者,对于另一直播数据就可能是参与者,甚至同时属于发布者和参与者。在下文中将以图1所示的P2P直播系统为例,对本发明方法的实现过程进行说明,但本领域技术人员应当了解,本发明的方法同样适用于其它P2P应用,如P2P点播平台上的数据传输、基于P2P技术的VoIP音频/视频电话的数据传输、基于P2P技术的视频会议的数据传输。
参考图2,对本发明方法的实现过程进行详细说明。
在图1所示的P2P直播系统中,所要直播节目的数据流的数据量很大,需要对数据流做分割操作。在本实施例中,对数据流分割操作是将一个数据流分割成多个数据分片,所述的数据分片是下文中所涉及的数据请求和文件传输操作的基本单位。每一个数据分片都有一个唯一的分片标识,一般而言,数据分片的标识按照时间顺序依次生成。如图5所示,一个数据流在做分割操作后,按照数据分片生成的时间顺序得到诸如标记为11、12、13的数据分片。
在得到数据分片后,还需要将各个数据分片分配到不同的组中。在一个实例中,根据分片标识模10的余数,可以将分片分为10组,每组称之为一个数据分组,或者子数据流。标识为0的子数据流指分片标识模10为0的数据分片所组成的子数据流,标志为1的子数据流指分片标识模10为1的数据分片所组成的子数据流,以此类推,在图5中示出了数据分片按照该方法分组的示意图。以这种取模方式打散数据流,可以确保某一子数据流中相邻数据分片标识保持一定距离,使得当负责某一子数据流传输的邻居节点意外退出服务时,客户端回放质量不会严重下降。虽然在上述实例中将数据分片分成了10个组,但在其它实例中,分组的数目可以根据用户的需要而改变,如5组、16组、20组皆可。虽然在本实施例中采用分片、分组的方式实现数据流的分割操作,但在其它实施例中,本领域技术人员也可以采用其它方式实现数据流的分割。
在完成数据流分割操作后,P2P直播系统中的任意一个客户端节点都可以发起直播请求,但在发起直播请求前,该客户端节点应当已经向P2P直播系统中的服务器注册,从而获取最新的节目列表信息,或通过访问P2P直播系统的网站获取最新的节目列表信息(步骤201)。用户在客户端节点根据节目列表信息选定所希望观看的直播节目,然后向负责该直播节目的Tracker服务器请求当前参与该直播节目的节点列表。为了将用户发起直播请求时所在的客户端节点与系统中一般的客户端节点相区别,在本发明中将用户发起直播请求时所在的客户端节点称为用户节点。用户节点在得到节点列表后,就可以按照一定策略从该列表中选择不超过邻居节点上限的数个节点作为该用户节点的邻居节点,并与这些邻居节点建立连接(步骤202)。以图1所示的P2P直播系统为例,假设有一客户端节点C为一次直播请求时的用户节点,则为其选定的邻居节点可以是节点A、节点B。在本实施例中规定邻居节点上限为5,在其它实施例中,邻居节点上限的数目可以根据情况而发生改变。
用户节点在选定邻居节点后,就可以为每个邻居节点维护一个推送记录表,该记录表中记录了一个邻居节点负责推送给该用户节点的子数据流信息,以及该用户节点负责推送给该邻居节点的子数据流信息(步骤203)。同样的,在各个邻居节点上也会维护一个与该用户节点有关的具有相似内容的推送记录表。在图6中给出了推送记录表的一个范例,假设图6所示的推送记录表中所包含的信息用于维护前面所提到的用户节点C与邻居节点A的子数据流推送关系。从该记录表可以看出:
(1)、在推送记录的输入行中记录的是A向C传输子数据流的情况。例如,在输入行,子数据流0列的标志为“0”,表明A当前并没有负责传输子数据流0的数据分片给C。
(2)、在推送记录的输出行中记录的是C向A传输子数据流的情况。例如,在输出行,子数据流n-1列的标志为“1”,表明C当前正在负责传输子数据流n-1的数据分片给A。
图6所示的推送记录表是用户节点C上的用于维护的C与A之间的子数据流推送关系的相关数据结构,但在邻居节点A上也会有类似的推送记录表。
推送记录表中的信息会根据情况而发生变化,在下面的说明中会结合推送记录表对相关步骤进行说明。
P2P直播系统中那些被选定为邻居节点的节点随机产生前述子数据流数目的全排列,然后各自按照该全排列的顺序发送相应子数据流给前述用户节点,经过随机竞争机制协调,最终确定每个邻居节点所负责的子数据流(步骤204)。在图3中对本步骤的具体实现过程做了说明,下面结合图3对如何确定各个邻居节点所负责的子数据流的过程做详细说明。
首先各个邻居节点要随机生成一个子数据流数目的全排列(步骤301)。例如,在前述的一个实例中,子数据流的分组数为10个,因此各个邻居节点随机产生整数从0到9的一个全排列,如邻居节点A产生的全排列为(1、2、9、0、5、3、4、6、8、7)。
接着,各个邻居节点按照前面所得到的全排列的顺序发送相应子数据流的数据分片给用户节点(步骤302)。仍以前文所提到的邻居节点A和用户节点C为例,邻居节点A需要向用户节点C推送数据,因此邻居节点A在根据全排列的顺序依次选取拥有相同子数据流序号的子数据流后,将该子数据流中分片标识最小的分片推送给C。如图5所示,如果当前正在处理全排列中的第一个数字1,则邻居节点A发送标识为1的子数据流中分片标识最小的一个,即标识为11的数据分片。
最后,用户节点在收到邻居节点所发送的数据分片后,检查本地所保存的与相应邻居节点有关的推送记录表(步骤303),根据推送记录表的相关记录对该数据分片进行处理。例如,用户节点C收到邻居节点A发送的标识为11的数据分片后,如果用户节点C中与邻居节点A有关的推送记录表中输入行代表子数据流1的标志位为“0”,则丢弃该数据分片,并发送拒绝消息给邻居节点A(步骤304);邻居节点A在收到拒绝消息后将本地与C有关的推送记录表中输出行的子数据流1列的标志位置“0”(步骤305)。相反,如果前述标志位为“1”,则用户节点C缓存标识为11的数据分片,发送接收消息给邻居节点A,并将本地与其它邻居节点有关的推送记录表中输入行子数据流1列的标志位置“0”(步骤306);邻居节点A在收到接收消息后,将本地与A有关的推送记录表中输出行的子数据流1列的标志位置“1”(步骤307)。虽然在上面的说明中,以邻居节点A为例,但对于其它邻居节点的操作也同样如此。
以上是对邻居节点确定自己所负责的子数据流的过程的说明。用户节点的各个邻居节点都要做上述的操作,直到完成对所有子数据流的分配(步骤308)。
各个邻居节点在确定自己所负责的子数据流后,会不断地将所负责子数据流中的各个数据分片发送给用户节点,当用户节点的缓冲区中所缓存的数据满足直播条件后,该用户节点开始在媒体播放器上回放直播节目(步骤205)。用户节点在缓存数据并开始播放后,还需要向Tracker服务器注册为数据提供节点(步骤206)。
在上述实施例中,通过竞争机制实现子数据流的分配,所有的子数据流都被指派给了一个,且仅一个邻居节点,并且与该用户节点通信能力较好的邻居节点会以较大概率承担较多的子数据流传输任务,这会提高P2P直播系统的整体性能。虽然在数据请求的初期会有较大量的冗余数据出现,但根据在
Figure G2009102356787D0000071
平台上的实践证明,所述竞争解决机制能够迅速减少冗余数据包的传输,并且会较快速地开始视频数据回放。
以上是对P2P直播系统实现数据传输的一个实施例的说明。在另一个实施例中,在前述实施例的基础上还包括用户节点对数据分片主动请求的过程。众所周知,P2P环境在将数据分发操作单纯由服务器完成改变为由众多客户端节点协同完成以加快分发速度的同时,也会遇到因为客户端节点随时关机或故障所造成的分发操作不稳定的问题。具体到前述的P2P直播系统,在数据流分发过程中,某一邻居节点可能会因为种种原因使得其所负责子数据流的数据分片推送过程终止,这将会影响与该邻居节点相关的用户节点所接收数据的完整性。因此需要用户节点主动请求相应的数据分片(步骤207)。
参考图4和图7,用户节点主动请求数据分片的实现过程包括:如图7(a)所示,为一数据分片设定一个未到达预警时刻,将该预警时刻记为twarning(步骤401),显然,未到达预警时刻应当在播放该数据分片的时刻之前,未到达预警时刻的设定可根据经验实现。在当前时刻tcurrent到达该预警时刻时,检查该数据分片是否已经到达了用户节点,如果仍然没有到达,则用户节点随机选取负责该分片相应子数据流的邻居节点外的其它邻居节点中的一个、多个或全部节点发送该数据分片的数据请求消息(步骤402)。
当邻居节点收到前述的数据请求消息后,检查其缓存中是否存在所述数据分片,如果存在则立即发送该数据分片给请求该数据分片的用户节点,否则直接忽视所述数据请求消息(步骤403)。
当请求数据分片的用户节点收到所述数据分片时,如图7(b)所示,如果当前时刻指针tcurrent小于最晚到达时刻指针tdeadline,则缓存所述数据分片到所述缓存区域的相应位置,否则表明该数据分片的接收时间已经晚于该数据分片的播放时间,因此直接将所述数据分片丢弃(步骤404)。对于用户节点而言,如果当前时刻指针tcurrent大于最晚到达时刻指针tdeadline,此时虽然数据并不完整,但为了实现直播节目的同步播放,只能以节目质量的损失为代价,将缺少所述分片的数据模块交由播放器播放(步骤405)。当然在本实施例中,由于P2P直播对时间的要求较高,所以在某些数据分片无法及时到达的情况下,可以丢弃这些数据分片。但如果在对时间要求不太高的其它P2P应用中,如P2P下载,则可以在接收到所有数据分片后才停止相关操作。
本实施例中,在数据分片无法及时到达的情况下,由用户节点主动请求相应的数据分片,实现了邻居节点推数据分片与用户节点拉数据分片的结合,与前一实施例单纯由邻居节点推数据分片相比,在数据传输质量上有很大的提高。
最后所应说明的是,以上实施例仅用以说明本发明的技术方案而非限制。尽管参照实施例对本发明进行了详细说明,本领域的普通技术人员应当理解,对本发明的技术方案进行修改或者等同替换,都不脱离本发明技术方案的精神和范围,其均应涵盖在本发明的权利要求范围当中。

Claims (8)

1.一种P2P环境下的数据传输方法,包括:
步骤1)、对所要传输数据做分割后得到多组子数据流;
步骤2)、在用户所登录的用户节点以及该用户节点的邻居节点上维护推送记录表,所述推送记录表用于记录所在节点所要推送以及所要接收的子数据流的信息;
步骤3)、所述邻居节点按照随机的顺序将不同组的子数据流推送给所述用户节点,所述用户节点接收子数据流后结合所述推送记录表中的信息为所述邻居节点分配该邻居节点负责推送的子数据流;
步骤4)、所述用户节点接收并保存所述邻居节点所推送的数据。
2.根据权利要求1所述的P2P环境下的数据传输方法,其特征在于,还包括:
步骤5)、所述用户节点在某些数据无法及时到达时,向除了负责该数据推送的邻居节点外的其它邻居节点请求该数据。
3.根据权利要求1或2所述的P2P环境下的数据传输方法,其特征在于,在所述的步骤1)中,对所要传输数据做分割包括分片、分组;其中,
所述分片包括将数据按照规定的格式大小分割,得到数据分片;所述分组包括将所述数据分片按照所述数据分配的标识进行分配,同一组的数据分片形成子数据流。
4.根据权利要求3所述的P2P环境下的数据传输方法,其特征在于,在对数据分片进行分组时,对所述数据分片的标识做取模操作,将标识取模后所得到的余数相同的数据分片分在同一组中。
5.根据权利要求1或2所述的P2P环境下的数据传输方法,其特征在于,所述步骤3)包括:
步骤3-1)、各个邻居节点对所述子数据流的序号做随机排列;
步骤3-2)、所述邻居节点根据随机排列结果将相应序号的子数据流按序推送给用户节点;
步骤3-3)、所述用户节点接收到某一邻居节点所推送的某一组子数据流后,根据自身的推送记录表的信息,决定是否将该子数据流分配给该邻居节点,并将决定后的结果通知该邻居节点。
6.根据权利要求5所述的P2P环境下的数据传输方法,其特征在于,所述步骤3-3)包括:
步骤3-3-1)、所述用户节点接收到某一邻居节点所推送的某一组子数据流后,若自身的推送记录表中记录拒绝接收该邻居节点所推送的该组子数据流,则向该邻居节点发送拒绝消息,该邻居节点接收到拒绝消息后,在其自身的推送记录表中记录,否则,执行下一步;
步骤3-3-2)、若用户节点自身的推送记录表中记录接收该邻居节点所推送的该组子数据流,则在该推送记录表中记录不接收其它邻居节点所推送的该组子数据流,并向该邻居节点发送接收消息,该邻居节点接收到接收消息后,在其自身的推送记录表中记录。
7.权利要求2所述的P2P环境下的数据传输方法,其特征在于,所述的步骤5)包括:
步骤5-1)、为数据设立未到达预警时刻;
步骤5-2)、在当前时刻到达该未到达预警时刻时,检查对应的数据是否已经到达了所述用户节点,若没有到达,则向除了负责该数据推送的邻居节点外的其它邻居节点请求该数据,否则不做操作;
步骤5-3)、所述邻居节点收到请求后,检查自身是否保存有相应的数据,若有,将该数据发送给所述用户节点,否则忽略该请求。
8.权利要求7所述的P2P环境下的数据传输方法,其特征在于,所述的步骤5)还包括:
步骤5-4)、若当前时刻大于最晚到达时刻时,所请求的数据还未到达所述用户节点,则抛弃该数据。
CN200910235678.7A 2009-10-12 2009-10-12 P2p环境下的数据传输方法 Active CN101697553B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN200910235678.7A CN101697553B (zh) 2009-10-12 2009-10-12 P2p环境下的数据传输方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN200910235678.7A CN101697553B (zh) 2009-10-12 2009-10-12 P2p环境下的数据传输方法

Publications (2)

Publication Number Publication Date
CN101697553A true CN101697553A (zh) 2010-04-21
CN101697553B CN101697553B (zh) 2012-07-11

Family

ID=42142627

Family Applications (1)

Application Number Title Priority Date Filing Date
CN200910235678.7A Active CN101697553B (zh) 2009-10-12 2009-10-12 P2p环境下的数据传输方法

Country Status (1)

Country Link
CN (1) CN101697553B (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102170475A (zh) * 2011-04-22 2011-08-31 中兴通讯股份有限公司 一种基于p2p的文件分发系统及分片方法
CN102457492A (zh) * 2010-10-20 2012-05-16 中国移动通信有限公司 流媒体文件的协同传输方法、系统以及设备
CN103037015A (zh) * 2012-12-31 2013-04-10 乐视网信息技术(北京)股份有限公司 一种p2p数据主动分发方法及节点客户端
CN106559413A (zh) * 2016-10-19 2017-04-05 深圳众享互联科技有限公司 P2p网络数据安全传输的消息碎片方法及其系统
CN110474846A (zh) * 2019-09-18 2019-11-19 中国银联股份有限公司 一种区块链中区块传播的方法及装置
CN111984322A (zh) * 2020-09-07 2020-11-24 北京航天数据股份有限公司 一种控制指令传输方法及装置

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101227590B (zh) * 2007-01-19 2013-03-06 北京风行在线技术有限公司 基于p2p协议的媒体文件点播控制方法及装置
CN101170430A (zh) * 2007-12-06 2008-04-30 北京广视通达网络技术有限公司 一种基于分布式p2p流媒体平台的广告发布方法
CN100571381C (zh) * 2008-04-18 2009-12-16 清华大学 P2p实时流媒体缓存替换的频道热度更新方法

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102457492A (zh) * 2010-10-20 2012-05-16 中国移动通信有限公司 流媒体文件的协同传输方法、系统以及设备
CN102457492B (zh) * 2010-10-20 2014-10-08 中国移动通信有限公司 流媒体文件的协同传输方法、系统以及设备
CN102170475A (zh) * 2011-04-22 2011-08-31 中兴通讯股份有限公司 一种基于p2p的文件分发系统及分片方法
WO2012142844A1 (zh) * 2011-04-22 2012-10-26 中兴通讯股份有限公司 一种基于p2p的文件分发系统及分片方法
CN103037015A (zh) * 2012-12-31 2013-04-10 乐视网信息技术(北京)股份有限公司 一种p2p数据主动分发方法及节点客户端
CN106559413A (zh) * 2016-10-19 2017-04-05 深圳众享互联科技有限公司 P2p网络数据安全传输的消息碎片方法及其系统
CN110474846A (zh) * 2019-09-18 2019-11-19 中国银联股份有限公司 一种区块链中区块传播的方法及装置
CN110474846B (zh) * 2019-09-18 2022-04-08 中国银联股份有限公司 一种区块链中区块传播的方法及装置
CN111984322A (zh) * 2020-09-07 2020-11-24 北京航天数据股份有限公司 一种控制指令传输方法及装置
CN111984322B (zh) * 2020-09-07 2023-03-24 北京航天数据股份有限公司 一种控制指令传输方法及装置

Also Published As

Publication number Publication date
CN101697553B (zh) 2012-07-11

Similar Documents

Publication Publication Date Title
CN101697553B (zh) P2p环境下的数据传输方法
US7925781B1 (en) Distributed storage to support user interactivity in peer-to-peer video streaming
CN101141459B (zh) 使用http与p2p相结合实现数据传输或流媒体传输的方法
US9853718B2 (en) Dynamically adjusting the transmission mode in a satellite communication system
CN101872555B (zh) 一种基于应用层组播的实时互动授课系统
CN101714987B (zh) P2p播放方法及系统
US8812715B2 (en) Method, system, and proxy node for P2P streaming media data distribution
CN103078847B (zh) 一种多码率流文件的存储和读取方法及相关装置
CN101394423B (zh) 一种媒体定位、搜索方法和系统
CN102075338B (zh) 基于分布式网络的直播方法和装置
EP2050007B1 (en) Method and system for transitioning streamed digital video content between stream servers in a digital video network
CN101945129A (zh) P2p流媒体直播的低延时传输方法及系统
CN1645858A (zh) 分布式对等流媒体的服务系统及其点播节目的实现方法
CN103281382A (zh) 一种基于p2p的文件传输方法和节点
Kim et al. Efficient neighbor selection through connection switching for P2P live streaming
US7143179B2 (en) Method and system for parallel data transmission on demand to an unlimited number of clients without acknowledgment and on the basis of constant data availability
CN102244642B (zh) 重定向方法、系统以及终端
CN101262360A (zh) 一种实时流媒体多点传输的方法和设备
Sato et al. P2MVOD: Peer-to-Peer mobile video on-demand
Meskovic et al. Content delivery architectures for live video streaming: hybrid cdn-p2p as the best option
Ha et al. Topology and architecture design for peer to peer video live streaming system on mobile broadcasting social media
CN101355432B (zh) 一种多点传输数据方法
CN102724201A (zh) 网络游戏系统以及在网络游戏系统中进行数据多播方法
JP2008263489A (ja) マルチキャスト配信装置およびマルチキャスト受信装置
Vassilakis et al. The impact of playout policy on the performance of P2P live streaming: or how not to kill your P2P advantage

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
C53 Correction of patent for invention or patent application
CB03 Change of inventor or designer information

Inventor after: Cheng Xueqi

Inventor after: Feng Kai

Inventor after: Li Jingyuan

Inventor after: Liu Yue

Inventor after: Wang Lei

Inventor after: Ye Jing

Inventor after: Lv Jianming

Inventor after: Lin Siming

Inventor after: Wang Yuanzhuo

Inventor before: Wang Lei

Inventor before: Ye Jing

Inventor before: Lv Jianming

Inventor before: Lin Siming

Inventor before: Li Jingyuan

Inventor before: Liu Yue

Inventor before: Cheng Xueqi

COR Change of bibliographic data

Free format text: CORRECT: INVENTOR; FROM: WANG LEI YE JING LV JIANMING LIN SIMING LI JINGYUAN LIU YUE CHENG XUEQI TO: CHENG XUEQI FENG KAI LI JINGYUAN LIU YUE WANG LEI YE JING LV JIANMING LIN SIMING WANG YUANZHUO