CoolStreaming/DONet: A Data-driven Overlay(翻译)

最新推荐文章于 2024-11-12 21:59:57 发布

hongleij

最新推荐文章于 2024-11-12 21:59:57 发布

阅读量1k

点赞数

分类专栏： P2P 文章标签：算法 playback buffer exchange algorithm parallel

P2P 专栏收录该内容

0 篇文章 0 订阅

订阅专栏

节点加入和成员管理

每一个DONet节点都有一个唯一的标识符，如ＩＰ地址，并维护一个成员缓冲池(mChache) ,包含了在DONet中活跃节点的标识符的部分列表。在一个基本的节点加入算法中，一个新加入的节点首先与源节点（origin node）联系，源节点随机的从自己的mChache选择一个代理节点，并将新节点转到代理节点。新节点可以从代理节点获取候选合作者（partner candidates）列表,并与这些候选者在覆盖网上建立合作关系。

这个过程通常是可行的，因为源节点在流的整个生存期内是存在的，并且他的标示符/地址是全局可知的。这种重定向能使新加入的节点有均衡/一致的合作者选择机制，并能减小源节点的负载。在本段的结束我们将加以改进。

一个实际中关键的问题是如何创建并更新mChache。为适应覆盖网的动态性，每个节点周期性的产生一条成员消息来声明自己的存在；每条消息是一个四元组，<seq_num , id, num_partner , time_to_live >,seq_num是消息的序列号，id是节点的标示符，num_partner是他当前的合作者数，time_to_live来记录消息的剩余有效期。我们采用Scalable Gossip Membership protocol, SCMP,在DONet节点间分发成员消息。[21]。在这里我们主要强调三个期望的性质：scalable , light-weight ,对每一节点一致的局部视图。在收到一条新seq_num的消息，DONet节点为节点id在自己mChache的更新相应条目（entry），如果没有这创建新条目。每一个条目是一个五元组<seq_num, id, num_partner,time_to_live,last_update_time>,前四部分来自收到的成员消息，第五部分为对该条目的最近更新时间（本地时间）。

下列的两种事件也能引发mChache的更新：(1) 成员消息通过流言被转发到其他节点 (2)节点作为一个代理节点,那些被包含在候选合作者列表中的条目.在任何一种情况下,time_to_live将减少current_local_time – last_update_time.如果新值小于等于0，且条目没有被转发或包含在合作者列表，条目将被移出；否则，num_partner在代理模式下将增加1。

B． Buffer Map Representation and Exchange

合作者关系和数据发送的方向都不是固定的。一个视频流被分成统一长度的segment,在每一个节点中segments的可用性信息由一个Buffer Map(BM)保存。每一个节点持续的于他的合作者交换自己的BM，然后调度哪一个片从哪个合作者去获得。

由于我们的目标是流媒体直播，在DONet节点中的视频回放进程是半同步的。我们的分析结果表明在DONet中包的平均发送时延是有界限的，实验更进一步说明节点间的时间间隔不大可能超过1分钟。假设每一个片的大小包含1秒的视频。一个120片的滑动窗口能有效地表达一个节点的buffer map,因为一个合作者对超出窗口的片没有兴趣。鉴于此，在我们的原形中，我们使用了120bit来记录一个BM,对每一bit,1表示一个片存在，0表示一个片不存在。滑动窗口的第一片的序列号由另两个bit记录。对于特别长的视频程序可以循环使用（>24 hours）。

C．Scheduling Algorithm

给定一个节点和他的合作者的所有BM ,一个调度算法将被产生出来用于从合作者获取期望的片。对于同质静态的网络，一种简单的轮询（round-robin scheduler ）将良好的工作；但对于一个动态和异构的网络，一种更加智能的调度算法是必要的。特别的，调度算法应当满足两大约束：每一个片的回放截止时间（playback deadline），来自合作者的异构媒体流带宽（译注：即每个partner的带宽状况都有可能不同），如果第一个约束不能得到满足，那么超出回放截止时间的片数应当尽量的少。这个问题是Parallel machine

Scheduling 的变体，这是一个NP-hard的问题[25]。因此并不容易得到最优解，尤其是当考虑到高度变化的网络状况。因此，为我们采用了具有快速响应时间的启发式方法。

我们的启发式算法首先每一片的潜在提供者（例如在缓存中包含该片的合作者集）.由于一个具有更少潜在提供者的片更不容易满足playback deadline约束.算法首先决定那些只有一个潜在提供者的片,,然后是那些有两个潜在提供者的,等等. 在多个潜在的提供者中,一个具有最大带宽并具有充足可提供时间的节点被选中.每个节点的调度算法的伪代码如图3.它的算法复杂的为O(W*B*M),在我们的实现中，每一次执行大约只需要15ms，这表明算法的负载时相当低的。

算法可以被经常执行来更新调度。

给定一个调度表，那些从同一个提供者获取的片被标记为类似BM的bit序列。然后这些片按序通过一个real-time transport protocol(实时传输协议) 传送,DONet并没有制定某一特定的协议；当前我们采用了TCP-Friendly Rate Control(TFRC)协议，正如在许多其他系统中所采用的。BM和调度结果同样可以通过捎带确认法（piggyback）来达到快速和低负载的更新。

注意origin node 只是作为一个数据提供者，而且他总是对于所有的片都是可提供的。通过有适应性的调度算法，他将不会被他的合作者的请求所淹没。如果需要，他也可以主动控制（proactive control）自己的负载，通过广播保守的buffer maps.例如，假如有M个合作者，origin node 可以设置自己给第k 个合作者的BM如下：

BM[idorigin node; i] =

0; if i mod M = k

1; if i mod M = k

也就是说，只有第( i mod M)个合作者能请求到origin node 的第i个包。而其余的片段将从其他合作者获取。

D. Failure Recovery and Partnership Refinement失败恢复和合作者优化

在DONet中，一个节点可能正常退出(depart gracefully ),也可能意外的崩溃。在任何一种情况下，两种情况都可以通过TFRC的空闲时间和BM交换来探测到。由于节点并发离开的可能性非常小，一个受到影响的节点会通过使用BM信息而重新调度从而很快的恢复过来。除了这种内在的恢复机制。我们提出了以下方法来提高恢复力：

Graceful departure(正常退出)：退出节点应当发布一条退出消息(departure message)，与成员消息(membership message)的格式相同，除了num_partner 字段被设为-1。

Node failure(节点失效): 一个合作者检测到某个节点失效将发布一条失效节点的退出消息。

退出消息通过与成员消息相似的流言传播，在节点失效的情况下，重复的节点退出消息可能会被不同的节点产生，但只有第一条收到的会被某一节点流言下去，而其他的重复消息将被压制。

每一个收到消息的节点将清楚退出节点的在mCache中的条目，如果存在。

最后，我们让每一个节点周期性的与从他的mCache中随机的选择一些节点来建立新的合作者关系。这一操作有两个目的：第一，在有节点退出的情况下，他能够帮助节点维持稳定数目的合作者；第二，它能够帮助每一个节点探索具有更优品质的节点。在我们的实现中，一个节点i使用函数max{S i,j ,sj,i},Si,j 是节点i从节点j单位时间内所获取的平均片数。直观上，一个具有更高带宽和能提供更多片的合作者将有一个更高的分数，而且，由于一个合作者可能是数据提供者或接收者，我们要充分利用两方面的带宽。在监测到一个新的合作者，具有最小评价值的节点将被拒绝来维护合作者的稳定数目。

这个数目，M，是一个非常重要的设计参数。我们的分析结果表明从源节点(origin node )到目标节点的平均距离为O(logN),而对于给定的距离k,覆盖率为