提供冗余数据流量控制特性计算器网络及相关方法与流程

本公开一般是与计算器网络有关，而且更特别地，与计算器网络数据流量管理有关。

背景技术：

随着连网技术的快速进展，视频数据已经变成许多应用程序中不可分开的部分。特别是，视频点播(Video on demand,VoD)是例如数字图书馆、远距学习、协作训练、公开信息系统、电子商务及娱乐等重要应用程序的核心技术。典型的VoD服务允许远程用户从存储在一个或多个服务器上的大量视频中回放视频。响应于服务请求，视频服务器以同步视频流的方式对用户传送视频。

一方面而言，无线网络的日益普及，另一方面结合了对于VoD资源无所不在的接入的需求，相对于要将可从视频服务器中获得的不断增加的数据量传送到增长的用户基础存在挑战。

举例而言，当存在对数据的高度需求(例如视频)的突然情况时，即会发生问题。例如，流行歌手麦可杰克森的死亡引起了对他的视频的高度兴趣的时期。当类似这样的情形发生时，对于相关视频的需求的大量增加会对其他正常视频与数据的正常接入有显著冲击。

已经使用了各种方式来对大量用户传播大量数据(例如视频流)。一种这样的方式是多播技术，它允许许多用户共享受欢迎的服务器流。然而，这种方式一般都需要所有的用户在指定的时间观看相同的数据，且因此无法在用户方便时“按需(on demand)”开始。

技术实现要素：

一种计算装置可包括存储器与处理器，所述存储器与处理器协作以按需从至少一个数据源接收要被中继到不同目的地的多个数据流，其中每个数据流具有与其相关联的各自的内容识别符。所述处理器可进一步根据与其相关联的各自的内容识别符确定针对第一目的地的第一个数据流何时与针对第二目的地的第二个数据流共享相同的数据，以及基于根据所述各自的相关联内容识别符所确定的第一与第二数据流共享相同的数据，暂停将第二数据流中继到所述第二目的地，并且开始将第一数据流中继到所述第二目的地。

更特别地，处理器可与存储器协作，以将第一数据流存储在存储器中，并且从所述第二数据流中暂停中继的位置处开始，将所述存储器中的所述第一数据流中继到所述第二目的地。作为示例，存储器可包括先进先出(FIFO)存储器。同样作为示例，第一与第二数据流可包括视频数据流。

此外，第一与第二数据流各具有与其相关联的各自的下游节点识别符。更甚者，处理器也确定所述第一与第二数据流何时具有匹配的下游节点识别符，并进一步基于所述匹配的下游节点识别符开始从所述存储器将所述第一数据流中继到所述第二目的地。处理器进一步用于确定何时终止将所述第一数据流中继到所述第一目的地，以及基于确定已经终止中继所述第一数据流，中断将所述第一数据流中继到所述第二目的地并且恢复将所述第二数据流中继到所述第二目的地。

内容识别符可被编码在各自的数据流中。此外，具有相同内容识别符的数据流具有相同内容，且处理器用于基于具有所述相同内容识别符的第一与第二数据流确定第一与第二数据何时共享相同数据。

同时也提供了一种相关的计算器网络，它可包括多个例如上文简要说明的计算装置。同时也提供了一种相关方法，以通过计算网络而按需将来自至少一个数据源的多个数据流中继到多个不同目的地，计算网络包括多个计算装置，例如上文简要说明的计算装置。

附图说明

本说明是参照如附图式加以进行，图式中绘示了例示具体实施例。然而，许多具体实施例都可被使用，且因此本发明不应被解释限于本文所提出的具体实施例。更确切地说，这些具体实施例是为了要让本发明更为透彻完整而提供。

图1为计算装置的示意图，所述计算装置用于执行根据示例方面的动态流合并操作。

图2至图3为一系列的示意图，说明了根据示例方面的动态流合并方法。

图4至图9为一系列的示意图，说明了在示例实施例中可与动态流合并方法一起使用的封包路由方法。

图10为传统路由方法及根据示例方面使用动态流合并的路由方法的数据速率对流数量的比较图。

图11为传统路由方法及根据示例方面使用动态流合并的路由方法的传输的字节对链路数的比较图。

图12a至图12d为一系列示意图，说明了可用于示例实施例的其他动态流合并技术。

图13a为示意图，说明了根据示例方面的多流式动态流合并场景。

图13b为示意图，说明了使用合并树的根据示例方面的示例动态流路由封包转发方法。

图14a至图14d为一系列的示意图，说明了动态流管理的示例缓冲管理方面。

图15为根据示例方面的例示动态流合并方法的状态转换图。

具体实施方式

一般而言，本公开提供了强健的网络数据接入环境，它可被用以提供需要的数据流量管理，即使是在对数据有不寻常的高度需求的突然情况下。特别是，本公开方法利用动态流合并(DSM)技术，其中相同的数据流会在通讯网络内的不同节点或路由器处被合并或共享，以保留网络资源(例如处理与带宽资源)，而且仍在不同时间或“按需”分配给不同的用户。更特别地，在此示出的方法可使用内容识别符来帮助确定两个视频流是否相同并且共享相同数据，不管原本是否被存储在不同服务器上以及具有不同的服务器目的地。类似于URL，内容识别符是被编码于视频流等中以助于重复检测。

先参阅图1，示例网络计算装置30(它可以是互联网，或其他的计算器网络节点，或服务器)例如示意性地包括存储器31以及耦接至存储器的处理器32。作为示例，处理器32可利用微处理器来被实施，而存储器可包括具有计算机可执行指令的非瞬时计算机可读取介质，以使处理器执行在此所述的操作。

更特别地，处理器32可以用于按需从不同数据源接收要被中继到不同目的地的多个数据流，其中每个数据流具有与其相关联的各自的内容识别符。处理器32可基于与其相关联的所述各自的内容识别符来确定对于第一目的地的数据流的第一个何时与对于第二目的地的数据流的第二个共享相同的数据。处理器32可基于根据与其相关的各自的内容识别符的第一和第二数据流分享相同的数据的确定，相应地暂停将第二数据流中继到第二目的地，并开始将第一数据流中继至第二目的地。

作为示例，内容ID可由数据内容供应者针对其本身各自的数据文件指定。举例而言，大的视频供应者(例如“亚马逊”(Amazon)或YouTube)可具有存储在不同服务器上的相同视频档案的多个副本，用于服务在多个位置中或来自多个位置的用户的冗余或效率，而且这些供应者会对这些文件使用其本身各自的内容ID方案。

另一种方法是，网络供应者(例如蜂窝或电信网络供应者)可对数据文件指定内容ID，或是利用网络将ID范围分配给各自的内容供应者，以将它们的档案流传输给用户。类似地，指定的内容ID注册服务可为以其注册的数据文件提供内容ID，例如类似于域名注册。以此方式，从不同的内容供应者(例如“网飞”(Netflix)、“葫芦”(Hulu)等)经由网络而流传输的相同文件会针对不同用户而被合并或共享，用户甚至不会知道。举例而言，若第一用户正在通过有线运营商的网络上从“网飞”流传输电影，而第二用户也通过有线运营商的网络上从“葫芦”流传输相同的电影，则有线运营商的服务器会暂停“葫芦”流，且反而对第二用户服务“网飞”流，即使所述第二用户并非“网飞”订阅者。

在一个示例实施例中，内容ID在所有内容供应者间都是唯一的。亦即，供应者可指定同一内容ID给他们的视频文件中的许多个视频文件。然而，分配给视频供应者的内容ID的集合可以是互相排斥的，亦即不会有两个内容供应者共享相同的内容ID。有些供应者会故意针对他们提供的相同视频(例如流行电影)共享内容ID。但在示例实施例中，只有具有相同内容的视频文件会携带相同的内容ID。

作为对比，在此示出的动态流合并技术并不会与其他现有的技术(例如内容分布网络(CDN)和对等网络(P2P)流传输)混淆。更特别地，本方法提供了智能型网络覆盖，其中可减少或消除重复的流量。更特别地参阅图2至图3，互联网消耗全世界能源使用量的大约5％左右。此外，估计约有90％的互联网流量是视频、而且几乎是“冗余”的。作为示例，大概有10％的最热门视频占了YouTube上总观看量的90％。因此，冗余数据会在互联网上重复传送。本方法提供了一种流量去重复技术，以供在视频源(视频服务器，或CDN中的代理服务器)及客户端之间更有效率的网络通讯。应注意的是，DSM也可直接被应用于实体网络(而不是覆盖网络)。

根据一个示例实施方式，装置30可被部署为智能型覆盖网络方法的部分，亦即作为部署于互联网主干上的“智能型路由器”。举例而言，在图2至图4的示例中，节点N2可被实施作为智能型路由器。每个视频流S₁、S₂在一系列的智能型路由器或节点N1、N2上从视频源被传送到客户端。在任何两个智能型路由器N1、N2之间传送的TCP封包仍可以根据IP协议而传送，如同在其他覆盖网络设计中。当智能型路由器辨识出正通过的两个视频流实际上是相同视频时，它会在稍后某时刻为较新的流重复使用来自较旧流的数据封包，并且请求上游的智能型路由器停止传送这个较新流以节省网络资源。应注意的是，除了互联网主干之外，智能型路由器还可被部署在网络中的任意处。一般而言，最有利的是将它们布置在具有高流量的位置处以获取及利用重复的流。覆盖设计是实际的部署策略，因为我们无法一次取代互联网中的所有路由器。随着旧的路由器被智能型路由器取代，覆盖网络即可递增地成长。

在所述示例中，节点N1注意到流S₁和S₂有相同的视频或内容ID(在此示例中为“CID123”)以及对下一个跃程的相同ID(亦即节点N2的ID)。因此，节点N1通知节点N2它要在片段5处开始合并两个流的意图。响应于此通知，节点N2开始将来自S₁的片段保留在存储器中，例如FIFO缓冲器。在从流S₂转发片段4之后，节点N2继续通过重复使用缓冲器中所存储的、来自流S₁的这些片段而转发后续的片段(亦即片段5、6、7等)，而且流S₂会被阻挡或中断。因此，在此示例中，S₂与S₁合并(S₁→S₂)。更一般而言，会是S₁→S₂→S₃→…→S_k，以保留k-1个流。

在每个智能型路由器的这种机会性流量去重复方法将覆盖的独立流动态地合并到流传输树中，这不同于多播树。多播树的所有客户端都是在视频流中相同的播放点处。相较之下，根据本方法的流传输树的客户端可以是在相同视频流中的他们本身各自的播放点处。这种新的能力能够开发对于视频点播(video on demand)的多播的效率。

此外，也应注意的是，所提出的覆盖与P2P流传输技术不同。在P2P设计中的对等点(例如BitTorrent)从给定视频的不同对等点处接收它的数据。本方法的智能型路由器根据路由算法从指定的智能型路由器接收给定的视频流。换言之，本方法是路由技术，而非文件共享技术。此外，P2P流传输并非如本方法中的去重复(de-duplication)技术，而且不会减少网络流量。

此外，也应注意本方法和CDN之间的差异。亦即，本方法是一种网络通讯技术，而非缓存技术。不同的流以线路速率合并于路由器结构中。当流传输树通信期终止时，视频数据不需要被缓存到智能型路由器中。相反的，视频会根据某些缓存取代策略(例如LRU)而被缓存于CDN中达一段非常久的期间。此外，使用代理服务器并不会节省这些服务器和它们的用户之间的带宽(亦即，并无流量去重复作用)。然而，根据本发明方法，这可利用区域性网络中的智能型路由器达成，且/或可节省互联网主干。

现将进一步参阅图4至图9说明示例合并场景。刚开始，流S₁在给定的网络节点处以封包P₁开始(图4)。在稍后的时刻，第二流S₂以封包P₁开始，第一流S₁在所述点则达到封包P₁₀₀。在基于第一与第二流S₁与S₂的各自的内容ID而辨识出覆盖时，流S₁会被记录(例如于FIFO缓冲器中)以准备进行流合并，如图6所示。更特别地，数据是以封包P₁₀₀开始存储于缓冲器中，并且一旦第二流S₂赶上封包P₁₀₀时，第二流S₂即被封锁或中断，并且现在传送来自缓冲器的数据封包(它们是存储自第一数据流S₂)来取代以封包P₁₀₀开始的第二流S₂，如图7所示。这会发生直到第二流S₂达到来自第一流S₁的最后封包为止，其将正常结束(图8)。在可选的实施方式中(图9)，当第一流S₁早终止或结束，第二流S₂会被解除封锁并且从当前位置继续，在所述示例中所述当前位置是在封包P₃₅₀处。

上述方法因此可用以实施视频流树，其中视频源可被连接至很多目的地，如同传统的视频流传输实施方式。然而，上述智能型路由器方法有利地为较新的流重复使用较旧的流的数据，从而控制冗余。此外，合并程序可持续地发展以为新请求服务并适应用户移动性的动态。这种机会性方法有助于节省珍贵的无线资源并增进网络的强健性，而不需要与视频源或用户协作。

另外参阅图10的图表100，为了说明以DSM方法达到的增益，执行使无线网格中的一组节点为可用的实验。使用线网格拓朴来允许最大数量的跃程(通常是在较大的网格网络中遇到)。网格网关通过以太网而连接至校园网络，并且启用NAT(网络地址转换)服务。在示例中，有n+1个用户，其中一个请求视频x，而所有其他用户在不同时间请求不同的视频y。这些用户被随机地放置于节点n2、n3与n4间。在图表100中，两条绘线101与102各自显示了实施DSM(DSM)与不实施DSM(Non-DSM)的视频x的数据速率。如图表线102所示，若无DSM，则对于视频y的渐增需求会产生与视频x相关联的延迟，因此视频x基本上是无法观看的。

根据关于网络压力的另一实验，现参阅图11的图表110加以说明，对于相同视频产生有20个请求。图表110中的绘线显示了在网络中每个链路处所传送的累积数据。如绘线所示，无DSM时会有较多流量，并且在最接近网关处其变成完全饱和。另一方面，有DSM时，接近网关的节点未饱和，并且可容纳更多的网格节点来支持甚至更多的流量。

网关负荷量的减少可产生较佳的网络利用，并可允许较大的网络部署。如上述说明，DSM在网关带宽上的需求相当低，其留下许多带宽供其他应用程序与用户使用。由于DSM并不会耗尽网关容量，因此可允许网络中的每个网格节点参与数据转发。换言之，更远离网关的用户也会使用网络并体验到优良性能。相反的，无DSM方式则会快速耗尽网关。严重拥挤会导致接近网关的许多封包丢失。因此，尽管在网络中存在有大量的活动流，但是更远离网关的网格节点仍几乎无数据可转发。

从前述结果可知DSM是用于流传输树的渐增架构与动态维护的分布式技术，它涉及相对少的开销，并且不需要与视频源或用户协作。此外，具有动态流合并能力的无线网格接入网络也会更强健、更有效率、并且对于大规模部署可扩展更多。

此外，关于典型对象(例如视频)识别符(例如URL)，驻留于不同服务器上的相同视频并不会被辨识为具有相同内容。然而，利用本方法，相同的内容识别符可有利地允许给定视频的不同副本被辨识为相同项目的重复，并从而为流量去重复提供更多机会。

现另外转向图12a-12d，现将说明示例DSM方法的进一步实施方面。随着连网技术的快速发展，如今视频数据已经变成许多应用程序中不可分开的部分。特别是，视频点播(Video on demand,VoD)是例如数字图书馆、远距学习、协作训练、公开信息系统、电子商务及娱乐(仅举几例)等重要应用程序的核心技术。典型的VoD服务允许远程用户从存储在一个或多个服务器上的大量视频中回放视频。响应于服务请求，视频服务器以同步视频流的方式对用户传送视频。

无线技术已经成为近年来最变革性与有威力的技术之一。利用例如802.11和WiMax的宽带无线技术，无线网格网络(具有网格拓朴的移动自组织网络(MANET)的特殊情况)已经被使用作为用于在住宅、商业、甚至是全城市的网络中提供宽带数据接入的边缘技术。在WMN中，无线网格接入路由器形成了类网格无线主干网络，它可允许终端用户通过网格网关在互联网或区域网中接入服务。用户可通过无线网格主干来接入VoD服务(例如IPTV服务器或视频共享服务器)。为求方便，这种网络被称为无线网格接入(WMA)环境。特别是，需要使网格网络中的流量达最小化，以实现设计更强健的WMA环境的可扩展方法。

针对每个视频服务请求使用专用的服务器流对于无线环境而言是非常昂贵的。当有大量用户想要流行内容时，它也具有受限的可扩展性。也会想要有可以承受特定视频的需求中的突然涌入的需求的强健无线接入环境。当这种事件发生，是不希望对于相关视频的需求的实质增加会显著影响对于其他一般视频的正常接入。

为了处理这个问题，可利用多播技术以允许许多用户共享流行的服务器流。作为有线环境的示例，修补技术可允许新的服务请求通过缓冲来自多播、正在进行的流来利用现有的多播，同时针对缺少的视频部分则从服务器播放新的“追赶”流。一旦被称为修补流的追赶流用尽，回放机制会切换为回放先前缓存于本地缓冲器中的多播数据，亦即共享多播数据。由于修补流非常短，它们并不昂贵且为客户端提供了可扩展的方式来共享进行中的多播。然而这种技术无法有效地用于WMA环境，因为当前的VoD服务器(例如YouTube网站的视频服务器)无法控制也无法支持边缘的WMN中多播。DSM技术可有利地被用以在WMA环境中有效支持VoD应用，其中视频服务器并不直接附加至WMN(例如，视频服务器是在互联网上)。

使用DSM来支持WMN中VoD的多播可渐增地形成多播群组，并且可适应地以分散形式在网格网络中执行路由，而不涉及VoD服务器。当服务器接收视频请求时，它为每一用户分配专用流。然而，当网络节点辨识出通过它的两个视频流具有相同的视频ID时，这两个流会被合并为单一流而保留节点资源。因此，多播机制对于互联网中的VoD服务器而言是透明的。DSM与传统多播的不同处如下：在传统技术中，是在服务器处作出要将用户群组化为多播群组的确定，而DSM在不知晓服务器的情况下动态地合并网络中正在进行的流。换言之，传统的多播依赖服务器上集中化的控制逻辑，而DSM是一种分布式控制技术，并且可更好地定位以作出网络感知协议的确定。

虽然下文说明的是VoD应用，但可理解DSM技术也可用于其他应用，例如现场直播。在这种环境中，最初接收来自广播源的分离的视频流的新的用户将会迅速看见在WMA环境中与另一流合并的这个流。

为了促进流在它们的视频中不同播放点的合并，我们为合并目的定义了视频片段作为单位。片段比网络的最大传输单元更大。举例而言，片段可以是视频中的图片群组(GOP)或用户定义的块(chunk)。在不失一般性的情况下，我们将视频流建模为一序列的非相同大小片段，并且使用sid(片段id)来表示流中每一个片段的序列号。

DSM是一种网络内流合并技术。为了在不同的视频通信期间共享数据片段(由于流合并)，可对网格节点提供每一个数据封包的sid、流ID以及视频ID(vid)。此外，内容ID可被用以辨识同一视频的重复副本，如上文所述。网格网关可将这类信息封装在每个数据封包中。举例而言，可针对RTP(实时传输协议)封包确定这些识别符如下。RTP标头中的序列号字段可针对作为sid的使用被调整。由于SSRC(同步源识别符)字段唯一地识别了来自在线服务器的RTP流的源，SSRC可结合源IP地址而被使用作为流ID。最后，URL(统一资源定位符)唯一地识别视频文件。

网格网关可以维护转换表，以将每一个正在进行的视频通信期的URL映射到视频ID中。当给定视频不再被使用于网络中时，它的当前视频ID就不再被需要，而可被循环以及未来用于另一视频。利用每一个网络包头中的前述信息，DSM能够在网络层中识别出正在进行的流及其片段，并基于所述信息处理封包。

图12a至图12d说明了简单的2-流合并情况。流S1与S2是通过节点N1的同一视频的两个数据流。合并是发生于两个阶段，分别如图12a与图12b所示。在这个示例中，节点N1目前接收流S1上的片段5(亦即，从S1读取的封包的最高sid为5)与流S2上的片段2。在阶段1中(图12a)，节点N1注意到这两个视频流具有相同的视频ID，并且通知节点N2想要合并这两个流的意图。亦即，对于节点N2而言，到达流S1的数据封包在下游中实际上是流S1与S2两者的“多播”封包，如图12b所示。作为响应，节点N2开始在本地FIFO缓冲器中节省抵达于流S1上的封包，从sid等于5的封包开始。在阶段2(图12b)，在节点N1转发流S2上的片段2、3与4的封包之后，其停止转发流S2的封包，尽管数据还持续到达(亦即，流S2被节点N1封锁)。在同一时刻，节点N2如同之前般继续转发流S1上的数据，同时它也将抵达的视频片段附加到FIFO缓冲器的后方。因为此缓冲器被馈送来自流S1的数据，节点N2亦从此FIFO缓冲器的前方取回封包(从片段5的封包开始)，并将它们于S2上转发至下游。

在上述示例中，若流S1被它的客户端终止(图12c)，或流S1的路径通过单播路由协议而从节点N1转向，流S2的客户端就不再能够从节点N1接收它的数据。举例而言，这种情况会发生在当节点N1尝试要接收流S1上的片段20时，如图12c所示。由于在这个时刻，节点N1在它的缓冲器中已经具有片段17、18与19，因此节点N1可继续在流S2上转发这些片段至下游。当这个FIFO缓冲器被耗尽时，节点N1可从片段20处开始恢复抵达流S2上的封包的数据转发(亦即，恢复正常的转发)，如图12d所示。我们注意到流S2的客户端仍取得所有的视频片段，并且不会受到在节点N1处的改变影响。类似地，如果流S2是在节点N1处停止，则节点N1会通过通知节点N2来自流S1的封包也不再是下游中流S2的“多播封包”而简单地取消合并。

流合并对于网络的动态而言是相对地弹性的。如上述示例所示，合并和取消两者都仅涉及两个节点(且在某些实施例中，这可由单一节点执行)。一般而言，多个流可被本地合并以共享无线带宽。此外，可并行地在每个网格路由器处自动运行相同程序，并且这些流将通过分布式控制逻辑而于整个网络中合并，以形成“多播”树。

利用两个节点进行流合并会具有某些优点。当两个流通过两个连续节点时，合并是在下方节点执行，并且因此可在这两个节点之间节省一个流。两个流中的“较新的”在合并之后继续抵达上方节点，上方节点并不会将此较新的流中继到下方节点。让此流继续抵达上方节点的原因是为了在较旧的流(较新的流是于下方节点上中继)提早终止时(亦即，观看者在视频结束之前就确定要停止视频)能快速恢复将此较新的流中继到下方节点。快速恢复中继是要避免在目的地的视频回放的抖动。此输入也与上述的解除封锁有关。

合并树(M-tree)可被用以支持每个网格节点处的流合并。给定两个网格节点之间的数据传输，我们称此传输的发送者为上游节点(UN)，并称接收者为下游节点(DN)。每个网格节点都使用进来的M-tree(iM-tree)与离开的M-tree(oM-tree)来分别记录与每个进来的流及每个离开的流有关的信息。M-tree的根节点代表正被接收或传送的实际流。节点是被称为其子代在M-tree中的合并者。子代节点被称为是母节点的被合并者。树型结构通知网格节点对应于被合并者的流已经与对应于合并者的流合并，亦即，合并者流“获取”了被合并者流。因此，这些被合并者流需要重新使用来自合并者流的视频数据。也就是说，它们共享了“多播”流。

在每个网络节点的数据转发可根据它的oM-tree执行如下。只有在oM-tree的根节点中所指示的流需要被转发。示例则如图13a与图13b所说明。如图13a所示，节点N1具有来自三个不同的上游节点的三个进来的流S1、S2与S3。这三个流共享相同的下一跃程，亦即节点N2。在通过节点N2之后，流S1与S2走到节点N3，而流S3走到节点N4。在这种情况中，这三个视频流是在节点N1与N2之间的链路处被合并。流S1与S2继续在节点N2与N3之间的链路被合并，而流S3则转向节点N4。

这些活动是在M-tree的帮助下完成，如下文所述。如图13b所示，两节点N1与N2都可具有在某单播路由协议上的处理器上运行的DSM软件。Pi(i＝1,2,3)表示针对流Si(i＝1,2,3)正在转发的视频片段的封包。节点1中的这三个iM-tree代表它有三个进来的流。然而，节点N1仅具有一个oM-tree，且它仅需要为流S1转发数据，如同这个oM-tree的根节点中所表示。在此例中，节点N2的iM-tree与节点N1的oM-tree相同。这允许节点N2可将进来的流解译为合并者流S1及它的被合并者(流S2与S3)的多播流。由于在节点N2处存在有两个oM-tree，需要为这两个oM-tree的根部中所指示的两个流S1与S3转发数据。封包P1是在流S1上转发。oM-tree指示这个封包也要给被合并者流S2。节点N2也在流S3上转发这个封包P3的副本。为了区别实际合并者流(例如流S1)的封包与被重新使用于被合并者流(例如流S2)的相同封包，我们并未说明作为图13中的离开封包的封包P2。

现在将参照图14a至图14d来说明示例缓冲器管理技术以及DSM的准入控制。令“块”(chunk)作为缓冲器管理的存储器单元。存储器块具有视频片段的平均大小。在不失一般性的情况下，假设是合并两个视频流S1与S2的情形，其具有d个视频片段的回放距离。亦即，在视频服务器为流S1送出d个视频片段之后，它开始为流S2传送数据。为了要在网格节点N1处合并流S2与流S1，节点N1需要维持有d个块的容量的FIFO缓冲器，以保留抵达于流S1上的视频片段而供于某时间之后在流S2上传输到下游节点。

在所述示例中，节点N1、N2的左手侧上的箭头是代表流S1，往右侧的箭头描写流S2。这个例子的初始状态如同图14a所示。在这里，回放距离为3个视频片段的两个流正在通过节点N2。为了合并这两个流，节点N2动态地分配有3个块的容量的FIFO缓冲器，如图14b所示。在这个图式中，节点N2继续为流S1与S2接收并转发视频片段。然而，节点N2也将抵达于流S1上的进来的片段7存储至FIFO缓冲器。当FIFO已满，此合并处理的最后步骤如同图14c所示。从这个时间起，节点N2会使用来自FIFO缓冲器的数据转发视频片段至下游中的流S2。在实施例中，是针对每个被合并者流使用专用的缓冲器，虽然也可使用其他技术以允许合并者的多个被合并者共享缓冲器。

在上述示例中，节点N2当前可能不具有足够的缓冲空间来容纳合并请求。简单的先来先服务准入控制策略被用来处理这种状况。当节点N1开始与节点N2的合并请求时，若节点N2没有足够的缓冲空间来容纳合并处理，则所述请求会被拒绝，且节点N1必须等待来自节点N2的合并通知，以于有较多的缓冲空间变成可用时再次尝试。为了支持这个策略，节点N2维持针对等待中请求的等待区域。当有较多的缓冲空间变为可用时，节点N2利用“最佳匹配”策略使用可用缓存空间来容纳可能最大数量的等待中请求。

DSM可实施为在单播路由协议顶部上的非易失性计算器可读介质软件模块、或为WMN中单播路由协议的非易失性计算器可读介质扩展(例如软件修补)。DSM可从路由层为每个视频流取得下一跃程节点的ID。这个信息可由WMN中使用的大多数单播路由协议提供，无论它们在网格网络中是维持完整路由、或是以逐一跃程的方式转发封包。

表I通信期表中的字段

在DSM中，WMN中的每个节点会监控目前通过节点的视频流，并且维持具有用于这些流的每个的条目(entry)的通信期表。上表I列出会在通信期表中的某些字段。具体而言，在网格DSM中，WMN中的每个节点都监控目前通过节点的视频流，并且维持有用于流的每个的条目的通信期表。网格节点会将为每个流所接收到的最高sid存储在字段“cur_sid”中。“merger”和“mergeelist”这两个字段是用来实施M-tree概念，如下述。对于通信期表中所记录的每个流S而言，“merger”字段记录了S的合并者(若S当前未在此节点的任何离开链路处被任何流合并的话，则其可以是S本身)，而“mergeelist”字段则包括S的被合并者的列表(若S当前在此节点的任何进来链路处并未合并任何流的话，则其会是空)。举例而言，让我们考虑图13a与图13b中的节点N2。流S1的字段“merger”与字段“mergeelist”分别是流S1以及{S2,S3}。类似地，流S2的字段“merger”与字段“mergeelist”分别是流S1以及空列表。一般而言，M-tree可比仅两个层级具有更多。然而，只有根节点会对应于正被接收或传送的实际流。以下说明通信期表中的其他字段。

两项操作，也就是合并操作(Merge Operation)与取消操作(Cancel Operation)，可被用以增进WMN中的流的动态合并与分开。合并操作在UN与DN之间的通讯链路处合并两个流。UN与DN彼此协作以通过更新它们自己的通信期表来更新受影响的M-tree。给定正被合并的两个流，具有较低cur-sid的流会被选择作为被合并者，而另一个流即为合并者。令合并者为X，被合并者为Y。合并流X与Y需要在UN与DM之间的握手，如下所述。UN对DN发送合并请求消息，这个消息含有与合并者X及被合并者Y有关的信息。

两种情况会产生。在第一种情况中，若DN准许合并请求，其将Y加到通信期表中的X的“被合并者列表(mergeelist)”。DN接着会对UN返回“Merge ACK”(合并确认)消息。在接收到“Merge ACK”消息之后，UN就将通信期表中流Y的“合并者(merger)”字段设定为X。UN也将DN的地址记录在Y的“merge_hop”字段中。这个字段是用于取消操作中的。另一方面，在第二种情况中，若合并请求无法被准许，则DN会对UN发送“Merge NACK”消息。在接收到NANK之后，UN将不再试图合并这两个流，直到它接收到来自DN的通知为止。

当合并操作成功时，分别位于合并者X与被合并者Y根部的两个oM-tree会在UN处合并。类似地，分别位于流X与Y根部的两个iM-tree会在DN处合并。取消操作的目的在于中断先前合并操作所建立的合并者(例如流X)与被合并者(例如流Y)之间的合并。在这个情形中，会发现流X与Y是在相同的M-tree中。此外，流Y对应于子树的根部，所述子树完全包含于以与流X对应的节点为根部的另一子树中。

取消操作是要将以流Y为根部的子数从受影响的M-tree脱离。类似于合并操作，取消操作可包括在UN与DN之间的握手，以确保两个网格节点都使它的通信期表被更新。UN可在合并操作之前通过查找通信期表中流Y的“merge_hop”字段来识别被合并者Y的DN。UN接着对这个DN发送“取消请求”(Cancel Request)消息。这个请求包含有与取消中所涉及的合并者及被合并者有关的信息。当接收“取消请求”消息时，DN会从合并者X的被合并者列表(mergeelist)中移除被合并者Y，并且返回“取消确认”(Cancel ACK)消息至UN以确认取消。UN接着将流Y的“merger”(合并者)字段设定成其自己。当取消操作成功时，以流Y为根部的子树会从含有流X的iM-tree和oM-tree脱离，并且分别变成新的iM-tree和oM-tree。

通信期表中的“status”(状态)字段可用以指示流的状态。举例而言，在DSM中会有四种状态，亦即NM(正常模式)、BM(“合并前”模式)、TM(终止模式)以及SD(流死亡模式)。NM状态指示正常流。根据一个示例，在合并操作中仅考虑NM模式的流。BM状态指示被合并流正处于合并操作中(亦即，DN尚未确认合并请求)。当UN最后自DN接收到指示合并操作成功的“Merge ACK”时，被合并者流的状态即从BM模式转换为TM模式。若合并操作失败，被合并者流会回到NM模式。最后、但并非最不重要的是，当流变成闲置时，NM、BM或TM模式中的流会转为SD模式。当有一段特定时间都没有进入的封包在这个流上抵达时，DSM可辨识出闲置的流。这会是各种无线条件的结果，例如链接失败、干扰或附近网络拥挤。当流的状态变为SD，则调用取消操作，因为并不需要合并闲置的流。SD状态仅对于给定流的正常数据转发恢复时才转为NM状态。

图15中说明了一种例示状态转换图表150。每一个网格节点都周期性地检查通信期表，并且根据“status”(状态)字段中的数值来触发合并操作与取消操作。根据一个示例实施例，针对合并操作，只有NM状态中的流可以是候选者。对于具有相同vid的流而言，具有在cur_sid数值中差异最小的流的对可触发合并操作。在合并之后，合并者保持在NM模式中，而被合并者的状态被改变为BM。这个程序会重复进行，直到通信期表中已经不再发现NM模式中的流为止。这个程序有助于确保流可具有多个被合并者，但只有一个合并者。

每一个网格节点也基于单播路由协议所提供的路由信息来周期性地更新通信期表中的“next_hop”(下一跃程)字段。流的下一个跃程会遭受因基础网络的动态的变化，例如链路故障或路由改变。若合并者与被合并者的“next_hop”字段不同、或任一“next_hop”字段变成无效，则会触发取消操作以取消受影响的合并。在执行合并操作与取消操作时，UN和DN会交换消息。多个操作的消息会在一个控制封包中被批次化，以减少通讯开销。

递归函数是被用来实施先前所述的数据转发方案。当进来的封包p抵达网格节点时，网格节点基于包头中的信息而找到它的对应流s。这个封包与它的流s被使用作为下表II提出的转发函数的输入。此函数呼叫的输入层级初始化为1。

表II递归转发函数

对于s的“mergee_list”(被合并者列表)中的每个流k而言，函数会产生p的副本(p_copy)并仿造p_copy的标头中的某些字段，例如“IP address”(IP地址)与“端口数”，以使其产生流k的封包。在行数3中，这个函数被递归呼叫以为流k处理p_copy。输入层级增加1，以指示输入封包是复制的封包、而不是来自最后跃程的封包。这种递归方案有助于确保在s的M-tree中的所有流都将以它们自己的封包而由这个函数处理。从行数4开始，函数作出流s转发确定。若流s是处于TM模式，则sid超过s的blocked_id的封包被删除。若流s不是处于TM模式，则函数于行数6验证层级，以得知输入封包是否为复制的封包。若p是复制的封包，它会针对s被存储于FIFO缓冲器中，并且在后续被转发(行数7)。否则，p就是从最后跃程抵达的封包，而函数会马上转发这个封包(行数9)。

根据另一示例方法，上述技术可被用于提供流量去重复技术，以在视频源(视频服务器或CDN中的代理服务器)及客户端之间实现更有效率的网络通讯。所提出的SMART(Small packet Merge-Able RouTers)覆盖网络利用了机会性流量去重复方法，并且使每个SMART路由器都可动态地合并相同视频内容的独立流，这形成视频流传输树(VST)。在最后被解复用及传送到与TCP协议完全兼容的客户端之前，合并的流会与TCP通信期信息一起穿隧通过覆盖。

我们检视SMART覆盖与当前覆盖多播方法一起作业，但对客户端与应用提供改善的服务的实施方式。多播网络是重要的通讯形式，特别是对于VOD、视频会议与对等式网络文件共享而言。这使应用可更有效率地使用资源，并且大幅增进了可扩展性。目前，对于多播有受限的网络层支持是受限的，且这已经导致应用转向互联网中的更高层级以取得服务。作为响应，覆盖多播网络被发展且被当前用于互联网中。覆盖多播节点与彼此及使用标准单播机制的主机通讯。覆盖网络对客户端或应用提供了较高端的服务，同时从基础网际网络提取数据。

SMART路由器可被安装在核心网络、以及安装在CDN与客户端之间，以创建覆盖拓朴，它将逐渐合并冗余的视频流，并且对客户端形成视频流传输树(VST)。这会有助于填补前述技术目前无法处理的间隙。在我们的SMART覆盖拓朴中所建构的VST与多播树不同。这些技术之间的两个主要差异如下：

1)在处理重复的VOD请求时，所建构的VST允许比多播树更多流量；以及

2)多播树通过视频的多播等待时间来限制客户端。相反地，VST在对客户端发送视频之前并不需要批次等待。

在当前的多播覆盖架构中，视频流会成为瓶颈，例如来自于视频服务器或CDN。此外，会有较多的流量通过其余网络链路。SMART覆盖拓朴结合多播覆盖将有助于减轻导致视频源的资源瓶颈，并且有助于减少其余网络的带宽需求，直到抵达最后节点为止。覆盖拓朴中形成的VST直接处理了互联网中去重复技术的需要。

安装有软件的路由器(称为SMART路由器)仍将如同平常作用，直到检测到视频为止。软件控制器将识别通过网络的视频，并且确定所述视频是新的、存在的，及/或存在且目前正在合并程序中的。为了确定它是否为视频，软件剖析封包的HTTP标头的“Content_Type”(内容类型)字段。若最上层媒体类型为视频，则控制器为所识别的此特别的视频指定视频id。否则，软件会将所述封包作为非视频处理，并如同平常地将它转发到下一个跃程。视频id是存储在合并表中的唯一识别符，以用于处理重复视频的查找。接着，控制器将会从封包中提取主机与目的地字段，并同样将它们存储在合并表中。合并表被使用作为查找表，以帮助维护路由器的状态并保持对路由器中发生的各种合并程序的追踪。软件的控制器部分也有助于将封包转发至覆盖拓朴中的邻近SMART路由器。若在视频ID中存在匹配，则软件接着将已识别的视频封包的抽象交递到冗余控制合并算法以处理合并程序。

SMART软件中的冗余控制合并(RCM)算法处理通过这些路由器的冗余视频。RCM有助于形成视频流传输树。视频流的合并是在SMART路由器的内部路由器结构中进行。

在路由层级的典型互联网架构包括以路由容量降次列出的核心路由器、聚集路由器以及边缘路由器。互联网中的流量拥挤是通过在路由器缓冲器中维护硬件队列加以处理。在示例实施例中，并不使用外部或代理缓冲器，而是使用可用于这些路由器中的内部路由器结构。这有助于减少等待时间以及在覆盖中实施冗余控制缓冲组件。

RCM在路由器中创建了多个迷你缓冲贮体(buffer bucket)来处理各种重复视频的合并。为了要帮助节省路由器上有限的缓冲器资源大小，当识别出视频时，合并程序并不会立刻开始缓冲程序。一旦识别出第二个冗余视频时，RCM将只创建迷你缓冲贮体。所使用的总缓冲空间是针对每个冗余视频所创建的迷你贮体的总和。为能更佳理解SMART路由器中的合并程序，SMART将在遇到第一个视频流之后执行下述基本步骤：

1)一旦控制器将视频流识别为原始视频，软件为此特别的视频流初始化母流(P1)。

2)当接收下一个视频流时，控制器检查冗余。

若所述视频是冗余的，则流将变成第一个子代流C1，并进行到下一个步骤。否则，软件将会初始化另一母流。

a)对于冗余的流而言，SMART软件记录相对于母流封包的冗余的视频(子代)开始的封包字节(指针)数。此记录被存储在合并表中，且每个子代流都被给定它自己的唯一的指针。

b)两个字节数量(P1与C1)之间的差异提供我们暂时的容量。这个暂时的容量被用来确定将用于合并对应的子代流的第一缓冲贮体的大小。缓冲器也将被用来向各自的客户端发送信息。

3)接着，RCM利用所记录的暂时的容量来分配它的路由器缓冲器中的空间，并且产生迷你缓冲贮体以开始存储部分的母流。在图2示例中，缓存是在第50个封包处开始，因为当C1抵达时，P1是在这个点。

4)一旦子代流C1追上缓冲器中的起始封包，两个流之间的合并会开始发生。接着，路由器将警示上游节点合并已经发生且现在可能会封锁C1。

5)回放会继续进行，直到C1已经全部被发送到客户端为止。

6)针对所接收的每个额外视频流(例如图2中的C2)重复程序。

a)若P1突然中断，则第一子代流C1将通过对服务器发送恢复请求而解除与从母流的合并。一旦母流中的剩下的封包(来自于缓冲器)已经被耗尽，则视频流将再次从视频服务器继续，C1也将成为C2的新的母流。

b)若C2抵达过晚而无法加入P1流，则它将变成视频的下一个母流(若有需要)。

部分或全部视频都可被缓冲于SMART路由器中，但路由器并不是非常长久地存储视频缓存。在针对特别视频的所有请求都已经完成处理后，缓冲器贮体即被释放。这个活动额外地让我们可以将路由器上有限的缓冲空间最大化，以处理更多的视频合并请求。最后，路由器上可用的全部缓冲器资源并不走到合并程序。SMART软件维持了可用于正常流传输的保留缓冲大小分区。

在示例实施例中，最佳的合并位置是对于在客户端与服务器之间的网络链路可达到的带宽节省最大量处。在建构的VST中，所提出的流合并策略是分散地在每个SMART路由器上运行。因此当从同一视频源开始的两个视频流的路由路径在它们分开前往两个客户端之前一起通过多个SMART路由器时，这些SMART路由器中的每一个都会自己独立地进行流合并操作。最终的合并位置可以是这些SMART路由器中的任何一个。

然而，就节省网络流量的观点而言，优化的合并位置应所述是最后一个SMART路由器，其中两个流恰在它们分开之前仍一起通过(如同图1中的合并结果拓朴)。下述分析显示，当涉及多个SMART路由器时，所提出的分布式流合并策略将于最佳位置处达成流合并。

在不失一般性的情况下，假设可以一起合并的两个流(S1与S2)在它们分开之前正通过相同的两个SMART路由器(R1与R2)，如下述图3所示。合并的最佳位置是指：若R1与R2都有资源，则合并应是在这两个流要一起通过的最后一个SMART路由器上进行，亦即在路由器R2上；若R2不具有任何合并的资源，则合并应所述要发生于下一个SMART路由器上(朝向视频源沿共同路由路径往前)，亦即在路由器R1上。注意这两个SMART路由器是独立地进行流合并。

现在说明确定如何达到最佳合并位置的示例方法。在不失一般性的情况下，假设第二流S2将要被合并至第一流S1。对于第一种场景而言，若R1和R2都具有合并的资源并且独立地进行合并，则会有两种可能的合并结果。若路由器R1先开始合并，则S2在服务器与R1之间的封包将会被舍弃。注意在此时刻R2还没有合并S2。当路由器R2稍后开始合并，它将会舍弃从R1接收的S2的封包，并且通知R1停止其合并活动(亦即丢掉S2的所有封包，并且仅转发S1的封包)。

若路由器R2先开始合并，S2在R2与R1之间的流量链路将会被移除，这将导致路由器R1舍弃它对于S2正在进行的合并活动，因为从R1观点，流S2不再会存在。

就两种情况而言，最后合并都将会保持在路由器R2上，也就是对于两个客户端而言的最后一个SMART路由器，且为最佳位置。

就第二种情景而言，当R2没有任何合并的资源时，R1开始合并，并且保持持有此合并，R1为这种情况的最佳合并位置。

此外，应指出分布式合并算法也可处理互联网路由中的动态。封包可通过不同路径而从服务器穿越到客户端，而且只要在路径上有一对SMART路由器，算法即可减少重复的封包。

综合言之，所提出的分布式合并策略最终能在最佳位置处达成流合并，而且不会浪费其他SMART路由器上的缓冲资源。

SMART覆盖将多个TCP通信期合并为一个流以节省带宽。一个挑战在于如何让它对于客户端的应用而言是透明的(亦即，对于每一个客户端应用而言，它仍在处理视频服务器)。SMART隧道技术即被设计以解决这个问题。

为了对隧道方法有更佳的理解，考虑视频源、SMART路由器(覆盖)与客户端(C1-C6)。为求简化，我们可称路由器A与C为核心路由器，而路由器B、D与E为边缘路由器。假设A正在为C1-C6合并视频流。路由器A会将封包与其目的地存储于合并表中。对于路由器A的合并表中的每一个封包而言，需要进行两件事情。首先，它查询路由表以计算出需要什么样的下一跃程来转发封包。在这种情况中，A仅需要对B发送一次封包，因为C1与C2的TCP通信期被合并了。而A到C亦然。其次，A将TCP封包封装于IP数据报中。IP的标头来源被设定为路由器A的IP地址。目的地地址被设定为下一个跃程(B或C)的IP地址。IP数据报的有效载荷是UDP封包。UDP封包具有隧道标头及含有TCP封包的有效载荷。隧道标头包括下列三个部分：类型、视频id，以及目的地列表。

视频id识别出正在路由器中进行合并的特别视频。IP标头中的类型字段识别出封包是否正在转发至下一个跃程，或者是否应要作为隧道封包(且遭受合并程序)而被处理。类型字段选项是被设定为要在封包重传情况下转发。最后一部分是元组的目的地列表(目的地IP、端口)。在这个例子中，其为关于封包A至B的C1与C2及A至C的C3-C6的信息。利用UDP有效载荷的IP数据报封装允许SMART路由器识别出作为隧道封包的封包。当路由器B(边缘)接收封包时，它会理解它是要递送C1与C2。SMART软件将接着为C1与C2制造封包(利用适当的TCP标头与有效载荷)，并且将封包各自传送至C1与C2。当C接收封包(并且为核心路由器)时，若它并未合并视频，则它会检查UDP标头。若其为隧道封包，则路由器将提取目的地并计算下一个跃程。在我们的示例中，C会以C3发送封包至路由器D，并以C4-C6发送封包至路由器E。

现在假设对于C1遗失了一些封包。视频服务器会重传这些封包，且封包会再次通过服务器A。其应将这些封包以穿隧方式送到C1并设定类型字段以在隧道包头中转发。所有的后续SMART节点都将仅转发封包。我们也需要处理中断连接与超时的TCP通信期。每个SMART路由器都为它所服务的所有客户端监控进来的流量。若客户端活动休眠一段时间，则路由器将停止对所述客户端转发流量。若有超时或拥挤，视频服务器将恢复发送封包，而我们的服务器也将恢复。

最后，为了降低SMART路由器(边缘)和客户端之间可能的拥挤，我们将起始修补技术。假设C1先到达SMART路由器，然后不久之后C2到达。当路由器A开始为C1与C2进行合并时，C1的流会变成母流。假设合并是在封包100处开始，路由器B将会接收到从100开始、连同封包1至99的C2的缓冲封包。在此例中，B将会缓冲封包，并且仅对C2传送先前缓冲的封包1至99(“修补”)。在那之后，B将对C2传送从100开始的缓冲封包。所述方法保证SMART覆盖并不会在边缘路由器及客户端之间造成所谓“最后一公里”的过度负荷。

发明所属技术领域中具有普通技术人员将可基于本文所提出的教示而得知本发明的许多修改与其他实施例。因此，应理解本发明并不限于在此所公开的特定示例性实施例。