应用层多播协议的多维特性研究.doc

第3期廖海宁等：应用层多播协议的多维特性研究121应用层多播协议的多维特性研究廖海宁, 卢锡城（国防科学技术大学 计算机学院，湖南 长沙410073）摘 要：从数据转发策略、服务模型、优化目标、优化技术和容错机制等5个维度综合研究分析了应用层多播领域的主要协议，并针对应用层多播协议设计过程中所需考虑的协议开销、可靠性、拓扑适配性、可伸缩性和优化目标等若干问题给出建议，最后对未来的研究作了展望。关键词：应用层多播；覆盖网；数据转发；优化技术；容错机制中图分类号：TP393 文献标识码：A 文章编号：1000-436X(2007)04-0114-09Research on multi-dimension features of application layer multicast protocolsLIAO Hai-ning, LU Xi-cheng(School of Computer, National University of Defense Technology, Changsha 410073, China)Abstract: A set of application layer multicast protocols were described and classified based on some properties such as data forwarding policy, service model, optimization objectives, optimization techniques, and fault mechanism. Then some recommendations were provided about the design of ALM protocols. Finally some important directions for future research are discussed.Key words: application layer multicast; overlay network; data forwarding; optimization techniques; fault mechanism1 引言随着网络技术的发展，诸如视频点播、视频会议、大规模分布式交互仿真、计算机协同计算等应用日益增多，多播已成为这些应用的关键支撑技术。收稿日期：2006-11-10；修回日期：2006-12-30基金项目：国家重点基础研究发展计划（“973”计划）基金资助项目(2005CB321801)Foundation Item: The National Basic Research Program of China (973 Program)(2005CB321801)IP多播需路由器的支持，它适用于时间同步、空间分布、实时不可靠的应用。由于各种原因，迄今为止IP多播在因特网上的部署仍是十分有限1，为此研究人员近年来提出了应用层多播。应用层多播将复杂的多播功能放在端系统实现，不需路由器的支持就可为广域网提供多播通信服务，它不仅可支持时间同步空间分布的应用，更可支持诸如视频点播等的时间异步空间分布的应用。应用层多播的发展深受媒体编码、P2P、自组织覆盖网、网络性能测量、覆盖网端到端拥塞控制和安全等使能技术的影响。目前常用的应用层多播协议性能评价标准可分为2类2：数据分发路径的质量和终端的性能。另外由于端系统的资源有限，故而需限制每个成员节点的邻居数，因此应用层多播树是度数受限的多播树。关于数据分发路径的质量，一般使用下列3个指标来衡量： 强度(stress)：流经某一物理链路或节点的相同报文的数量。 展度(stretch)：覆盖网中源到组成员的路径长度与单播路径长度的比值，常用跳步数表示。通常还可表示为RMP和RAP，RMP是覆盖网中源到组成员的最大时延与单播最大时延的比值，RAP是覆盖网中源到组成员的平均时延与单播平均时延的比值3。 代价：应用层多播树的代价可表示为覆盖网链路时延之和。通常用TCR(tree cost ratio)来表示资源消耗情况，TCR是覆盖网多播树代价与对应的网络层多播树代价之比4。关于终端性能，常使用下列3个指标来衡量： 控制开销：反映多播协议用于维持覆盖网络所交换的控制信息数量及其所占用的带宽。 失效后包丢失率(loss after failure)：单点失效后的平均包丢失情况，反映协议的顽健性。 首包等待时间(time to first packet)：一个节点加入传输会话开始到接收到第一个包的时间间隔。虽然应用层多播从提出至今不到十年，却已涌现了许多针对不同应用、具有不同性能优化目标和服务模型的协议526，如最早提出的应用层多播系统ESM使用Narada5实现了中等规模的视频通信，并已成功地应用于SIGCOMM 2002/2003、OSP 2003和NOSSDAV 2004等国际会议，P2P文件共享系统Jungle Monkey和因特网距离测量系统IDMaps均用到了BTP7。文献27根据系统结构将应用层多播系统分为对等型519、代理型2023和服务器型243类，文献28根据控制拓扑和数据拓扑的生成顺序将应用层多播系统分为网优先4,5, 20,23、树优先610,21,22,24,25、隐式法11,12和基于特定逻辑结构13,15,264类。这2种分类方法均较少考虑多播协议的优化目标及其采用的优化技术，且文献28认为应用层多播的数据转发均是沿着多播树进行，忽略了使用多源协同服务的这一类协议。为了更全面了解现有的应用层多播协议，并对多播协议中常用的性能优化技术的优缺点有明确认识，论文提出了多维度分类方法，并据此来研究分析并阐述当前主要的应用层多播协议。2 应用层多播协议的多维度分类方法论文提出的多维度分类方法综合考虑了应用层多播协议设计过程中所需考虑的问题，包括数据转发策略、服务模型、性能优化目标、性能优化技术和容错机制等5个维度，多维度分类方法同时还克服了现有分类方法的不足。根据数据转发策略，应用层多播协议可分为2类：基于树和基于多源协同服务。多源协同服务的思想是参与节点之间不一定有固定的逻辑拓扑结构，数据被划分为若干数据块，所有正在下载的节点可从源节点，或其他节点协同地获取它所需要的数据块29，此类协议主要有文献1619。基于树的思想是数据的转发沿多播树进行，因多播树的构造和优化算法深受服务模型、优化目标、优化技术和容错机制的影响，因此下面从这4方面来给出基于树的多播协议的分类方法。根据服务模型，协议可分为单源和多源2类。支持单源的协议只需构造一棵以源为根的多播树即可，而支持多源的协议可以使用源多播树、单棵双向组共享树、单棵单向组共享树或多棵组共享树中的任一种来转发数据。根据性能优化目标，协议可分为以下几类：最小代价或最小资源消耗、最小延迟、可伸缩性和带宽。最小延迟可以细分为2种，一是源到任一成员的最大延迟最小，即根直径最小；二是组中任两个成员间的最大延迟最小，即树直径最小。根据性能优化技术，协议可分2类：分布变换和局部集中调整4。分布变换包括switching和swapping 2个操作，switching是某个节点改变父节点，swapping是2个节点同时交换父节点。局部集中调整通常最多只涉及到多播树中相邻两层以内的非子孙节点，主要操作有：1) 子节点提升成为父节点的兄弟节点；2) 父子节点相互交换；3) 具有相同祖父节点的两个节点相互交换位置；4) 具有相同祖先的2个节点相互交换位置，如节点x的父节点是节点y的祖父节点，x与y相互交换位置。根据容错机制，协议可分为3类：采用编码技术和多棵树、反应的(reactive)和主动的(proactive)。采用编码技术和多棵树的容错机制在组成员之间同时维护多棵多播树，利用多描述编码把流数据编码成N个媒体流，每个媒体流同时沿不同的多播树传播，每个组成员收到N个媒体流中的任何M(M N)个就可完成解码；反应类协议是在节点失效或离开多播会话后才开始多播树的修复工作；而主动类协议则是在节点失效或离开之前就预先为多播树中非叶节点的每个子节点计算备用父节点。下面首先介绍基于树的应用层多播协议，然后是基于多源协同服务的应用层多播协议，最后是应用层多播协议的容错机制。3 应用层多播协议的服务模型和优化特性下面从多播服务模型、性能优化目标与性能优化技术3个维度阐述各类主要的基于树的应用层多播协议，有ACDC8、TBCP9、OMNI21、HMTP24、NICE11和Overcast22。其中ACDC、TBCP、OMNI和Overcast均只支持单源应用，HMTP和NICE支持多源应用， Overcast的优化目标为源到节点的带宽最大化，NICE是可伸缩性，OMNI是平均延迟最小化，ACDC和HMTP是代价最小化，根据所使用的配置函数TBCP的优化目标可为代价最小化或延迟最小化。3.1 ACDC8ACDC属于单源最小代价分布变换类协议，它为单源应用构建度数受限和根直径受限的最小代价多播树。为了保证延迟受限，ACDC的每个节点保留从根到其子孙节点的最大时延信息。新成员首先从RP处获取当前成员列表，然后随机选取多播树中的某个成员作为初始父节点。加入多播树后，每个节点执行收集与分发2个操作。在收集阶段，从叶节点开始每个节点向父节点报告其子孙集合及其他信息；一旦根节点接收到来自所有子节点的信息后，根节点进入分发阶段，使用文献30提出的RanSub技术来向每个子节点发送一个探测集，直至到达叶节点为止。然后又开始新一轮收集/分发阶段。当节点接收到探测集后，执行到目标节点的探测工作并根据需要切换到某个目标节点，每个节点保留在测量过程中发现的最佳候选父节点的信息，并将此信息发送给当前父节点。3.2 TBCP9根据所使用的配置函数，TBCP既可属于单源最小代价局部集中调整类协议，也可属于单源最小直径局部集中调整类协议。TBCP的局部区域调整只涉及到新节点、侯选父节点和侯选父节点的子节点。新节点加入时会测量其与局部调整范围内所有节点的距离，并将测量结果报告给侯选父节点，侯选父节点根据计分函数为所有可能的局部配置打分，选择分值最优的配置来安排新节点。TBCP所有可能的局部配置如图1所示4。图1 TBCP局部配置为了优化多播树性能，除根节点外其他所有节点均周期性地运行节点加入过程以发现更好的父节点，此时的加入过程是从根路径中随机选择的某个节点开始。3.3 OMNI21OMNI属单源最小直径分布变换类协议，它为单源实时应用构建度数受限的平均延迟最小化的生成树。OMNI是一个两层的基础设施，由分布在网络中的称为MSN的设备组成，MSN向一组主机提供有效的数据分发。OMNI的目标是最小化源到整个客户集的时延，因此OMNI需根据客户在MSN之间的分布动态调整覆盖网的结构。所有的MSN自组织成一棵以源MSN为根的多播树。多播树的生成分为初始化和局部优化2个阶段。在初始化阶段，MSN的根节点首先测量它到其他MSN节点的延迟，并按递增顺序排序；然后在树的每一层，在度数受限的前提下选择离它最近的MSN节点。在局部优化阶段，本地MSN通过与邻近MSN的交互，如多播树中两层以内的MSN，来执行某种局部变换(交换或迁移)，从而缩短平均延迟。MSN可采用的局部变换如图2所示21，每次MSN都会选择相对优化目标而言改进最大的局部变换。OMNI的局部变化涉及到新节点、祖父节点、父节点、父节点的兄弟节点和后二项的子节点。上述局部变换只考虑了多播树中的近邻，故不一定能实现平均延迟的全局最优。为此OMNI引入概率转换，即每个MSN执行概率局部变换，并以较低的概率与通过随机漫步方式在多播树中定位的另一个MSN相互交换位置。图2 OMNI局部变换与TBCP相比，OMNI不仅使用局部调整，还使用随机漫步和概率转换技术以期达到全局性能最优。3.4 HMTP24HMTP是多源最小代价分布变换类协议，它构造一棵度数受限的最小代价双向组共享树实现数据分发。HMTP使用应用层多播来桥接IP多播，每个IP多播域内的某个成员被选举为DM，每个DM均运行HMTP，DM间用UDP互连。DM类似于多播域内的多播路由器。新成员h使用深度优先搜索算法来确定多播树中距自己最近的侯选父节点。h首先询问RP获知共享树的根节点；然后从根节点开始，在树的每一层h试图找到一个离自己最近的成员x；若x的度未超过度约束，h成为x的子节点，否则向下一层推进并试图在x的子节点中找到一个可能的父节点。可见HMTP在新节点加入时就尽可能将新节点置于最优位置，以便于多播树尽快收敛。新节点仅需搜索树的一部分即可找到父节点，不过父节点不一定是距新节点最近的节点，物理上邻近的节点在共享树中通常会聚集在一起形成簇。HMTP要求每个成员周期性地运行节点加入过程以发现更好的父节点，不过此时的加入过程是从在根路径中随机选择的某个节点开始。3.5 NICE11NICE是多源局部集中调整类协议，其优化目标为协议的可伸缩性。NICE将成员组织成一个分层的控制拓扑，每一层的成员形成多个大小为k到3k1的簇，其中k为常数。每个簇有一个簇首，簇首到簇中其他成员的最大距离最小。所有的成员都位于最底层L0，层Li的所有簇首组成层Li+1。NICE将位于最顶层的簇的簇首设为RP。任一层的每个簇的控制拓扑是个完全无向图，而数据拓扑是个星形结构。数据转发过程如下：源使用泛洪方式将数据转发给同一簇内的成员，然后源所在簇的簇首再将数据以泛洪方式转发给超簇（簇首在上一层所属的簇）内其他成员，超簇内的每个成员将数据转发给其在各层所属簇的其他成员，如此往复直至每个成员均接收到数据。新节点加入时从位于最高层的簇首开始，根据节点间的时延使用深度优先搜索算法来定位层L0的距自自己最近的簇。每个簇的簇首周期性地检查所属簇的大小，若超出了规定大小3k1则执行簇分割操作，若低于规定大小k则执行簇合并操作。在执行簇分割操作时，要求分解所得的簇的最大半径最小。每个成员H(假设位于层Li)周期性地探测其超簇中的所有成员，来决定离自己最近的成员(假设为J)。若J不是H在层Li所属簇的簇首，那么H就会离开当前簇，加入到J在层Li所属的簇。因此NICE的优化是通过局部集中调整来完成，此时只考虑了父节点的兄弟节点。与NICE类似的协议还有Zigzag，二者区别在于：NICE把簇的管理和数据分发这两个功能放在簇首这一个节点上；Zigzag将簇管理交由簇首，数据分发交由称为副簇首的另一个节点。Zigzag可以提高系统的可靠性，不过Zigzag规定数据只能由副簇首流向非簇首成员，反之不行，因此Zigzag只能支持单源，不支持多源。 由NICE协议可知，最坏情况下NICE成员所需的控制负载为，平均控制负载为O(k)，数据转发路径长度为。因节点度数与它所在的层次有关，最大度数有可能为，故NICE协议不能保证满足节点度数受限这个条件，因而不适用于带宽密集型多播应用。因簇首直接影响其他成员的性能，因此NICE不适合异构环境。实验结果表明31，NICE可在时延和代价间取得较好的平衡，但NICE协议的收敛性较差。3.6 Overcast22Overcast是单源分布变换类协议，其优化目标为带宽，即Overcast构建源到每个节点的带宽最大化的分发树。新节点最初作为根的子节点加入到多播树中，然后开始多轮探测以定位距根更远的节点作为父节点。在每一轮探测中节点评估到达根节点的多条路径的带宽，一是节点通过父节点到达根节点的路径带宽，二是节点通过父节点的任一子节点到达根节点的路径带宽，若2类路径带宽相当，则父节点的某个子节点就成为新的父节点(若有多个子节点满足条件则选取最近的，即traceroute返回的跳步数最少的子节点)，接着再开始新一轮的探测。Overcast根据10kB的下载时间来评估带宽。可见Overcast是在不牺牲根路径带宽的前提下，强制性地将每个新节点尽可能放在多播树的下游。每个Overcast节点周期性地测量与其兄弟节点、父节点、祖父节点的带宽，以确定是否需更改自己在多播树中的位置，如将祖父节点置为新的父节点，或将某个兄弟节点置为新的父节点。除了上述协议外，还有一类协议是通过路由协议生成、优化分发树，这些基本属于网优先协议。如Narada5和Gossamer20通过在网格上运行DVMRP得到源多播树，CAN-Multicast13、Scribe14和Bayeux15则是通过DHT路由实现数据分发。由于Pastry和Tapstry这类DHT算法本身就具有树型逻辑拓扑结构，因此Scribe和Bayeux分别使用Pastry和Tapestry管理组的创建、组成员的加入和退出、多播树的维护及数据的分发。这类算法的优点在于可以充分利用DHT算法所带来的树收敛快、可扩展性好、本地化性强、自治性强、负载平衡等优点，但由于DHT算法本身并非是针对应用层多播设计的，树中转发节点可能不是多播组的参与节点，且DHT算法的逻辑拓扑并不一定与物理网络拓扑适配，这些都会导致转发时延增加，效率不高。4 应用层多播的多源协同服务特性应用层多播树中下游节点的吞吐量会受到上游节点带宽的限制，且中间节点的退出或失效会导致其子节点数据接收的中断，为了提高数据分发的可靠性和吞吐量，研究人员提出了基于mesh的应用层多播协议，也称为基于多源协同服务的应用层多播协议，Bullet16、DONet17、Anysee18和CollectCast19等都属于此类协议，其中Bullet是典型代表。所有的Bullet节点可采用已有的技术，如Narada、NICE、Overcast、Scribe或RanSub32等，构建一个以源为根的多播树。从源节点开始，每个Bullet节点向子节点传输数据的不同部分。源节点将数据分成顺序块，每个块再细分为若干独立的对象，所有的对象将被依次发送到网络中不同的节点。任一节点从父节点处接收对象，且负责定位拥有其他对象的对等节点。Bullet数据分发过程表示如图3所示16。图3 Bullet数据分发Bullet主要有4个组件：Data Encoding、RanSub、Informed Content Delivery和TCP Friendly Rate Control。Data Encoding根据传输数据的不同类型采用不同的编码机制，当然也可不对数据做任何编码。RanSub使用collect和distribute消息在多播树中分发成员的随机子集，在collect阶段每个成员向父节点发送由若干随机挑选的子孙节点组成的collect set，在distribute阶段每个成员向子节点发送由若干随机挑选的远程节点组成的distribution set。Informed Content Delivery指的是当通过RanSub定位到拥有不同数据的对等节点后，采用文献30提出的近似一致技术来核对数据间的差别。Bullet使用去掉了重传机制的TFRC(TCP friendly rate control)，即只有在一个RTT内发生了多个报文丢失时Bullet才降低报文发送速率。Bullet使用其他覆盖网组织协议实现多播树的生成、维护和优化，而其他基于多源协同服务的协议，如DONet，使用gossip协议来管理成员关系，节点间没有固定的逻辑拓扑结构，根据数据的可用性动态决定数据的转发，数据的流向无固定方向。5 应用层多播的容错特性由于端系统的转发性能和可靠性均不如路由器，端系统随意加入和退出可能性偏大，因此需考虑当出现节点失效或退出时，未失效的节点间仍能正常通信且能自动从覆盖网的分割状态中恢复并快速收敛到有效的覆盖网拓扑，即应用层多播协议需考虑容错机制的实现。可以将容错机制分为3类：采用编码技术和多棵树、反应类和主动类。CoopNet33是一种典型的采用编码技术和多棵树实现容错的应用层多播协议，由第2节可知CoopNet是同时从控制平面和数据转发平面来提高端到端的可靠性。CoopNet的缺点在于，多播树维护开销较大，多描述编码需占用较多网络带宽，且多路同时传送下数据的同步是个难点。文献57,9,1113,21,22属于反应类协议，文献4,8,14,15为主动类协议。这2类协议均是只从控制平面来提高数据分发的可靠性。实验结果表明34：反应类协议多播树恢复所需时间一般情况下是主动类协议的2倍，在特殊情况下可能达到主动类协议的5倍。此外，PRM35提出的随机转发方法则是从数据转发平面来提高可靠性，它要求每个覆盖网节点不仅要向子节点转发数据，还需随机选择常量个其他覆盖网节点并以低概率向这些节点转发数据，这样可保证即使出现了节点失效仍能有较高的数据传输比率。一般多播应用中随机转发方法带来的额外流量所占比重不到5%，然而在实时转播情况下额外流量所占比重会有较大上升。关于基于多源协同服务的应用层多播协议，因一份数据同时存在于多个节点，因此可以认为这类协议是从数据平面来提高数据分发的可靠性。6 分析比较表1列出了各类基于树的应用层多播协议的比较。从前面的论述可以知道，在分布式应用层多播协议中，新节点常采用下述方法定位初始父节点：随机选取方法，如ACDC、Narada和Gossamer；根节点方法，如HMTP、TBCP、OMNI、Overcast和NICE。在覆盖网或多播树的维护和优化过程中，可通过下述方法发现多播树中的其他节点：根路径，节点x到根所经过的覆盖网路径；分布式深度优先搜索；局部区域，通常由多播树中邻近一层或两层以内的节点组成，如TBCP、NICE和Overcast；随机漫步；RanSub，如ACDC和Bullet；Gossip，如Gossamer和DONet。优化时可以同时运用多种方法，如HMTP综合使用了根路径和深度优先搜索，OMNI则同时使用局部区域和随机漫步。依据所使用的发现侯选父节点的方法，多播树优化技术可分为分布变换和局部集中调整2类。局部集中调整因其探查范围受限，故而只能达到局部性能最优，而随机漫步方法可扩大节点探查范围，因此多播树优化时综合运用局部区域和随机漫步方法能以较快速度达到全局性能最优，即收敛速度较快，通常在多播树初期以较高的概率使用局部区域，后期则以较高概率使用随机漫步。当然也可在优化阶段同时使用深度优先和随机漫步。分布变换通常通过根路径、深度优先搜索、RanSub、Gossip或随机漫步等一种或多种方法来获知覆盖网或多播树中其他节点的信息，比如可同时运用根路径、深度优先搜索和随机漫步这3种方法来构造和优化最小代价多播树，该方法不仅收敛速度快，而且生成的多播树与节点加入顺序无关4。使用深度优先搜索的协议，物理上邻近的节点在多播树中会聚集在一起形成簇，此时覆盖网拓扑与物理网拓扑的适配性较好。使用基于簇的分层拓扑的协议也具有这个优点。通常，最小代价与最小时延是2个相互矛盾的性能指标，只考虑最小代价所生成的多播树往往时延较大，而只考虑最小时延所生成的多播树往往链路的强度较大且代价较高，因此在设计多播协议时需在此二者间权衡，即应考虑构造度数、时延受限的最小代价树或度数、代价受限的最小直径树。 Narada类的网优先协议通过运行DVMRP等路表1应用层多播协议特性比较协议数据转发策略服务模型优化目标优化技术容错机制节点最大度数最大路径长度节点状态信息组规模ACDC多播树单源时延受限+最小代价Switching主动c时延受限中等TBCP多播树单源最小代价/最小直径局部集中调整反应c最大不限中等OMNI多播树单源最小直径局部集中调整+Swapping +概率转换反应c最大不限大HMTP双向组共享树多源最小代价Switching反应c+1最大不限O(c)中等NICE多棵源多播树多源伸缩性局部集中调整反应最大平均超大Overcast多播树单源带宽Switching反应c最大不限大Narada多播树多源时延根据效用函数增加/删除链路反应m最大不限中等Scribe单向组共享树多源伸缩性Pastry路由主动Pastry邻居数：多播树： c大c表示节点的最大子节点数，m表示网格中节点的最大邻居数，n表示覆盖网节点数，K为NICE最大簇大小，b为Scribe的设计参数。中等表示支持的组成员数目为数百，大表示支持的组成员数目为数千，超大表示支持的组成员数目为数万。由协议得到源多播树，因此在多源多播情况下数据转发的时延能得到较好保证，但此类协议的控制开销为O(n2)，因此只能支持组成员为几百的中等规模组。基于簇的分层协议在时延与代价之间能取得较好平衡，比如NICE，其平均时延优于共享树4，平均控制开销为常量，因此基于簇的分层协议可伸缩性好，能支持组成员数目达几万的超大规模组，但由于它们不能保证节点度数受限，因此这类协议不适于异构环境。如何为多源多播构建度数受限、控制开销适中的最小直径多播树有待进一步研究，除了源多播树、共享多播树和分层协议外，还可考虑多核多播树4。基于特定逻辑结构的应用层多播协议，如CAN-Multicast、Scribe和Bayeux，它们通过DHT路由实现数据分发，利用DHT算法管理和维护多播树，具备可伸缩性好和负载均衡等优点，能支持组成员数目达几千的大规模组，但不足之处是覆盖网的逻辑拓扑不一定与物理网拓扑适配，可能导致转发时延增加，以及协议控制开销较大。一般的树优先、对等型或服务器型多播协议通常能支持组成员数目达几百的中等规模组，如TBCP和HMTP。为了支持更多的用户，应用层多播系统可考虑采用代理型体系结构，即使用应用层多播来桥接IP多播，此时多播协议通常能支持组成员数目达几千的大规模组，如OMNI、Overcast和Scattercast。为了提高数据分发的可靠性，缩短节点失效所需的恢复时间，可从控制平面上采用主动类的容错机制。在条件许可的情况下，还可综合使用随机转发方法以从数据平面来提高可靠性。当然基于多源协同服务的多播协议本身就提供了冗余的数据分发。综上所述，对基于树的应用层多播协议来说，1）如果关注协议控制开销，可选择树优先协议或基于簇的分层协议；2）如果关注可伸缩性，可选择分层协议，或者基于DHT路由的协议，或者使用代理型的体系结构；3）如果关注优化技术，为了加快协议的收敛速度，建议加入随机漫步技术和概率转换；4）如果关注优化目标，应同时考虑多播树代价和直径； 5）如果关注拓扑适配性，可考虑基于深度优先搜索的协议或分层协议；6）如果关注多源多播，可考虑源多播树，单棵组共享树或多棵组共享树，若需构建源多播树可考虑网优先协议或分层协议； 7）如果关注可靠性，可考虑同时从控制平面和数据平面来提高覆盖网端到端数据分发的可靠性。与基于树的协议相比，基于多源协同服务的应用层多播协议可靠性高和可伸缩性好，但时延不好控制。可以看出不同的多播应用具有不同的服务质量要求，因此在设计应用层多播协议时必须针对不同的应用需求来综合考虑选用不同的设计方案。7 结束语目前关于应用层多播的研究中，主要集中于覆盖网构建、维护和优化算法，所考虑的应用多为视频会议、网络电视等流媒体应用。下一步的研究工作可考虑针对其他不同应用需求来设计应用层多播协议，如分布式交互仿真所要求的高吞吐量、多级别可靠、低时延和低抖动。未来的研究主要解决下列问题：覆盖网端到端的拥塞控制和可靠传输；NAT和防火墙所带来的可达性问题；节点的自私性所引起的可信问题；安全保证，如加入多播组控制、对读取多播组内传递的数据控制、避免转发数据被篡改等。此外覆盖网的组织和优化算法也有待进一步研究。参考文献：1DIOT C, LEVINE B N, LYLES B, et al. Deployment issues for the Ip multicast service and architectureJ. IEEE Network,2000, 14(1): 78-88.2EL-SAYED A, ROCA V, MATHY L. A survey of proposals for an alternative group communication serviceJ. IEEE Network, 2003, 17(1): 46-51.3CASTRO M, JONES M B, KERMARREC A, et al. An evaluation of scalable application-lavel multicast built using peer-to-peer networksA. IEEE INFOCOMC. San Francisco, 2003. 1510-1520.4TAN S W. Constructing Efficient Self-organising Application Layer Multicast OverlaysD. UK. the University of Kent, 2005.5CHU Y H, RAO S G, ZHANG H. A case for end system multicastA. Proceedings of ACM SigmetricsC. 2000.1-20.6FRANCIS P. Yoid: extending the internet multicast architectureEB/OL. /yoid, 2000.7HELDER D A, JAMIN S. End-host multicast communication using switch-trees protocolsA. Workshop on Global and Peer to Peer Computing on Large Scale Distributed System (GP2PC)C. Washington, DC, USA, 2002.419-424.8KOSTIC D, RODRIGUEZ A, VAHDAT A. Scalability and Adaptivity in Two-Metric OverlaysR. Department of Computer Science, Duke University, CS-2002-10, 2002.9MATHY L, CANONICO R, HUTCHISON D. An Overlay Tree Building Control Protocol in Networked Group CommunicationR. London, UK, 2001. 78-87.10WANG W J, HELDER D, JAMN S, et al. Overlay optimizations for end-hostmulticastA. Fourth International Workshop on Networked Group Communication (NGC)C. Boston, USA, 2002. 124-131.11BANERJEE S, BHATTACHARJEE B, KOMMAREDDY C. Scalable application layer multicastA. Proceedings of ACM SigcommC. 2002. 205-220.12DUC A, TRAN, KIEN A, et al. A peer-to-peer architecture for media streamingJ. IEEE Journal on Selected Areas in Communications, 2004, 22(1): 121-133.13RATNASAMY S, FRANCIS P, HANDLEY M, et al. A scalable content-addressable networkA. Proceedings of ACM SigcommC. 2001. 161-172.14CASTRO M, DRUSCHEL P, KERMARREC A M, et al. Scribe: a large-scale and decentralized application-level multicast infrastructureJ. IEEE Journal on Selected Areas in Communications, 2002, 20(8): 1489-1499.15ZHUANG S Q, ZHAO B Y, JOSEPH A D, et al. Bayeux: an architecture for scalable and fault-tolerant widearea data disseminationA. NOSSDAV 2001C. 2001. 11-20.16KOSTIC D, RODRIGUEZ A, ALBRECHT J, et al. Bullet: high bandwidth data dissemination using an overlay meshA. Proceedings of the 19th ACM Symposium on Operating System PrinciplesC. 2003. 282-297.17ZHANG X Y, LIU J C, LI B, et al. CoolStreaming/DONet: a data-driven overlay network for peer-to-peer live media streamingA. Proc of IEEE INFOCOM 2005C. 2005. 2102-2111.18LIAO X F, JIN H, LIU Y H, et al. Anysee: peer-to-peer live streamingA. Proc of INFOCOM06C. 2006. 274-278.19HEFEEDA M, HABIB A, XU D, et al. Collectcast: a peer-to-peer service for media streamingJ. ACM/Springer Multimedia Systems Journal, 2003,14: 4-10.20CHAWATHE Y. Scattercast: An Architecture for Internet Broadcast Distribution as an Infrastructure ServiceD. University of California, Berkeley, 2000.21BANERJEE S, KOMMAREDDY C, KAR K, et al. Construction of an efficient overlay multicast infrastructure for real-time applicationsA. IEEE INFOCOM 2003C. 2003.1521-1531.22JANNOTTI J, GIFFORD D K, JOHNSON K L, et al. Overcast: reliable multicasting with an overlay networkA. Proc of USENIX Symposium on Operating Systems Design and ImplementationC. 2000. 197-212.23CLAUDIU D. Performance and Functionality in Overlay NetworksD. Baltimore: The Johns Hopkins University, 2004.24ZHANG B C, JAMIN S, ZHANG L X, Host multicast: a framework for delivering multicast to end usersA. Proc of IEEE INFOCOM02C. 2002. 1366-1375.25SHI Y S. Design of Overlay Networks for Internet MulticastD. Washington University, Saint Louis, Missouri, 2002.26LIEBEHERR J ,NAHAS M,SI W. Application layer multicasting with delaunay triangulation overlaysJ . IEEE Journal on Selected Areas in Communications ,2002 ,20(8) :1472 - 1488.27曹佳, 鲁士文. 多播技术研究J. 信息技术快报，2004.CAO J