AnySee

已经有两类基于在覆盖图内部（intra-overlay）优化的方法被提出了，基于树状的覆盖图（tree-based overlay）和基于网状的覆盖图(mesh-based overlay)。尽管原有的组播方法得到了优化，但是仍旧困扰于较长的延迟和突然的中断，尤其是当大量的peer同时加入网络的时候（为什么这个时候会有突然的中断？）。

所以呢，基于覆盖图与覆盖图之间（inter-overlay）的优化算法被提出了。这种算法的主要思想是：不但要像早先的算法那样利用一个overlay中的网络和计算资源，但是还要利用不同的overlay中的节点的计算资源。好像记得一篇文章中提过这样的事情，就是一个正在看CNN的用户，其有宽裕的带宽资源，所以他会替一个正在收看BBC的用户转发视频流中的包。通过这样的方法可以更大限度的使用网络的带宽，均衡网络的数据流。使用户具有更好的使用体验。

接下来，我们来描述一下AnySee的工作方式，第一步，建立一个高效的，基于网状的覆盖图（使用了基于位置探测器的算法来匹配物理层的拓扑，啥意思？这里有个关键组件忘了提了，mesh-based overlay manager）；第二步，单覆盖图管理器（single overlay manager关键组件之一）（利用传统的覆盖图内部的优化算法）来处理加入和离开覆盖图的节点；第三步，覆盖图间优化管理器（inter-overlay optimization manager又一个关键组件）探索合适路径，建立备份连接（backup links），裁剪QoS比较低的分支；第四步，关键节点管理器（key node manager）分配有限的资源，缓冲管理器（buffer manager）管理和调度视频数据的传输。

在AnySee中，每个节点首先要加入到基于网状的覆盖图中，每个节点都有一个标识符，该节点首先连接初始节点，然后挑选一个或者几个节点来建立逻辑连接。每个节点维护一组逻辑邻居。这个步骤的关键就是要让基于网状的覆盖图于网络节点的物理拓扑相匹配。这个mesh-based overlay manager使用一种叫做LTM（Location-aware Topoloy Matching）的技术来优化覆盖图，找到最近的邻居避免慢速的连接。主要使用两种方法flooding-based detection with limited TTL和updating logic connections。这两种算法我也没有看得太过明白，我这里就先不展开了。

接下去是Single Overlay Manager，这个组件主要是用来管理peer的加入和离开操作的。在覆盖图之间的优化开始之前，一个peer首先加入一个覆盖图，至于是接受来自于一个节点还是多个节点的数据，是取决于单覆盖图优化的结果的。在这个设计中，引入了一个新的属性，叫做LastDelay，意思就是说，从当前这个节点通过每一条去达源节点的路径中，产生的最小的那个延迟。（不过，关于这个延迟怎么计算，论文里说得很不清楚，这让我也比较疑惑）

一般来说，每个节点维护一个活跃流路径集和一个备份流路径集。最初，所有的流路径都是由Single Overlay Manager来管理的。当备份流路径小于最初的数值的时候，覆盖图间优化算法被启动了，用以在全局范围内找到一个合适的流路径。当一个活跃的流路径由于比较差的QoS或者某个节点的离开而被剪掉的时候，一个新的流路径会从备份流路径中选择出来。这也就是说，一开始，一个覆盖图还仅仅涉及到一个源，如果某条路径的断裂，或者QoS小于某个值了，将会导致发起全局范围的路径探索，最终促成了全局范围的优化。这一段后面很详细的阐述了这个算法，我现在实在是没有勇气在这里来描述，先放着。

然后我简单描述一下关键节点管理器，这个东西的作用就是帮助管理富余的资源的，还是，我掠过算法不讲，只讲思想，首先这个组件将所有的富余的资源管理起来假如有N个，然后将向本节点发起的请求也管理起来，将他们排入M个队列，然后将富余的资源逐一分配给请求队列，分配的过程遵循一些算法。

最后，缓冲区管理器用来管理收到的和发送出去的数据包，这里使用的算法和CoolStreaming里面的算法是一致的，但是由于CoolStreaming里面没有使用覆盖图之间的优化算法，为了降低延迟，其缓冲区设计得都比较大，也就意味着较高的播放延迟，而在AnySee中，这个缓冲区就可以设置得比较小，相应的在播放延迟的问题上，将要获得更好的性能。