专利名称：用于移动tv的鲁棒文件传播的利记博彩app
技术领域：
本发明总体涉及内容分发，具体涉及一种用于提供有效修复机制的方法和设备。
背景技术：
本节意在向读者介绍与以下描述和/或要求保护的本发明的各个方面可能相关的技术领域的各个方面。相信该讨论有助于向读者提供背景信息，以便于对本发明各个方面的理解。相应地，应当理解，应据此阅读这些声明，而不应当将其作为对现有技术的接纳来阅读。
现在，通过蜂窝网络在移动终端上暂时观看TV节目已经是可能的。在DVB-H中定义的广播协议增强了服务质量和商用服务的可能性。移动TV试验以及第一商业活动集中于传统的实况TV服务。
可以在移动广播网络(例如DVB-H)和双向网络(例如蜂窝3G网络)上构建推文件传送服务。基于文件的视频传送服务的一个优点是网络问题(例如带宽约束和分组丢失)上的相对灵活性。
基于一些标准，根据智能调度，推送视频点播(VOD)服务通过广播多播网络(例如，DVB-H)向终端用户设备传输视频文件，这些标准包括优先级、用户预订、网络状态(测量例如带宽可用性)、动态内容分类、调度历史等等。将这些与用户偏好相匹配的文件保存到终端用户设备上的本地存储器。这使用户能够在没有播放延迟并且几乎不考虑底层传送机制的情况下访问多种内容。在标准"ETSI EN 301192 VI.4.1 (2004-11) Digital Video Broadcasting (DVB); DVBspecification for data broadcasting"和"ETSI EN 302 304 VI.1.1 (2004-11)Digital Video Broadcasting (DVB); Transmission System for HandheldTerminals (DVB-H)"中定义了 DVB扁H。
移动广播网络是单向网络，其中可以使用前向纠错(FEC)来部分地解决分组丢失。然而，使用FEC机制是消耗带宽的，并且不保证
完全恢复的文件。这对于以下无线移动广播网络来说是尤其正确的在该无线移动广播网络中，当用户移动至覆盖较差的区域(例如隧道)
中时，终端可能错过大段的数据。此外，在当前DVB-H接收器实施方式中，根据标准"ETSI TR 102 377 Vl丄l (2005-02) Digital VideoBroadcasting (DVB); DVB画H Implementation Guidelines",如果不能使用FEC来完整地修复包括若干IP分组的分组突发(burst of packet),则忽略该分组突发。那么，可能丢失若干重要的IP分组。
另一种用于避免分组丢失的技术在于发送相同的文件若干次。该技术可以完全适用于短文件，例如在标准"DVB-IPDC ESG, ETSI TS102 471 V 1.2.1 (2006-09), Digital Video Broadcasting (DVB); IPDatacast over DVB-H: Electronic Service Guide (ESG)"中指定的电子服务指南容器。但是该技术对于视频文件传送来说明显是不太有效的机制。
文件修复或鲁棒文件传播是另一种保证用无线电传输的视频文件的完整性的方法。特别地，文件修复或鲁棒文件传播完全适用于增强用户观看体验的推送VOD服务。
在由第三代合作伙伴计划、多媒体广播多播服务组
(3GPP-MBMS)制定的标准"ETSI TS 102 472 Vl.2.1 (2006-12),Digital Video Broadcasting (DVB); IP Datacast over DVB-H: ContentDelivery Protocols"中描述了后传送文件修复协议。该协议还被描述在由数字视频广播-汇聚广播多播系统组(DVB-CBMS)制定的标准
"ETSI TS 126 346 V6.1.0 (2005-06)， Universal MobileTelecommunications System (UMTS); Multimedia Broadcast/MulticastService (MBMS); Protocols and codecs (3GPP TS 26.346 version 6.1.0Release 6)"中。文件修复机制是所谓的关联传送过程的一部分；主要过程是基于FLUTE协议套的文件传送，其中，基于单向传输的文件传送(FLUTE)在RFC 3926中指定。文件修复协议的目标是提供一种取回丢失分组和/或先前根据文件传送过程而接收到的文件片段的方式。每当应已经完全接收到文件时，开始文件修复过程。在FLUTE中难以检测文件的结束。可以对文件的最后一个FLUTE分组进行标记以发信号通知文件的结束。然而，如果该分组丢失，则接收器必须依靠文件传送表(FDT)。 FDT是与要作为FLUTE协议一部分而在频带中发送的文件有关的一组信息。这样的信息可选地包含文件的大小。然而，根据RFC 3926， DVB-CBMS推荐使用指示当前基于FLUTE协议而传输的文件大小的FDT传输长度参数。 一旦据推测应接收到文件，接收器就检测丢失的FLUTE分组并与修复服务器建立连接。根据退避(back-off)算法，接收器在正确时间发送一个或多个请求并获得丢失的分组，并保存完全重构的文件。
可以将该机制与类似于DVB-CBMS所推荐的raptor码的应用FEC相结合。接收器仅请求成功运行FEC解码过程所必需的分组。
然而，接收器可能没有接收到FDT。此外，大小信息作为强制扩展报头而存在于FLUTE分组报头中，该强制扩展报头收集包括传输长度在内的FEC传送信息。并且，在每一个FLUTE分组中传送报头扩展不是强制的。最后，如果接收器尚未检测到任何先前信息，则可以使用监视计时器来安全地关闭文件。由于两个分组之间经过的时间不是恒定的，因此必须谨慎地使用监视计时器。
发明内容
本发明通过提供修复网关来尝试修正现有技术中与文件修复相关的问题中的至少一些，该修复网关对更适合请求设备的修复服务器进行选择。
本发明涉及一种用于在以下系统中、在修复控制设备处从多个修复服务器当中选择修复服务器的方法，在所述系统中，至少一个终端以及所述多个修复服务器收听以推模式从至少一个文件服务器分发的至少一个文件传送会话。
为此，所述方法包括以下步骤从所述至少一个终端接收针对修
复所述至少一个文件传送会话的分组的请求；选择用于修复发往所述
至少一个终端的分组的修复服务器；以及利用所选择的修复服务器的地址，将所述请求重定向至所述至少一个终端。
文件修复机制是基于允许任意接收器修复先前通过单向广播网络接收到的文件的点对点协议的。该方案扩展了增强鲁棒性和可扩縮
性的DVB-IPDC禾n3GPP-MBMS后传送文件修复机制的可能性。本发明的方法提供了对修复过程的集中式控制，该集中式控制通过在发送请求时提供最佳修复服务器来改进修复过程的效率。这完全适于包括在大网络中分散开的多个修复服务器在内的网络。
根据实施例，所述方法包括以下步骤将来自终端的、针对修复所述至少一个文件传送会话的分组的后续请求重定向至所选择的修复服务器。
本发明还涉及一种用于在以下系统中、在修复控制设备处从多个修复服务器当中选择修复服务器的方法，在所述系统中，至少一个终端以及所述多个修复服务器收听以推模式从至少一个文件服务器分发的至少一个文件传送会话。
为此，所述方法包括以下步骤从所述至少一个终端接收针对修
复所述至少一个文件传送会话的分组的请求；选择用于修复发往所述至少一个终端的分组的修复服务器；以及将所述请求转发至所选择的
修复服务器。
根据实施例，所述方法包括以下步骤将来自终端的、针对修复
所述至少一个文件传送会话的分组的后续请求转发至所选择的修复服务器。
根据实施例，修复服务器是第一类型的或第二类型的，其中第一类型的修复服务器仅正确地接收由文件服务器传输的分组的一部分，而第二类型的修复服务器正确地接收由文件服务器传输的所有分组。
所述选择步骤包括以下步骤对第一类型的修复服务器进行分类；从
分类的第一至最后一个修复服务器，相继地发送针对修复分组的请求，直到接收到具有指示的响应为止，所述指示是关于修复服务器可确保
的修复的百分比的，其中所述百分比满足阈值；如果修复服务器满足所述阈值，则选择修复服务器；以及如果列表的最后一个修复服务器没有提供满足所述阈值的百分比，则选择第二类型的修复服务器。根据实施例，修复控制器按照从负载最少到负载最多来对修复服 务器进行分类。
根据实施例，修复控制器选择与所述请求设备最接近的第二类型 的修复服务器。
根据实施例，所述文件传送会话是基于单向传输的文件传送会话。
根据实施例，所述选择步骤包括以下步骤决定使用多播修复以 及选择第二类型的修复服务器。
本发明还涉及一种修复控制设备，包括通信装置，用于在以下 系统中与多于一个修复服务器以及至少一个终端进行通信，在所述系 统中，所述多于一个修复服务器以及所述至少一个终端收听以推模式 从至少一个文件服务器分发的至少一个文件传送会话；选择装置，用 于在从所述至少一个终端接收到修复请求时，在所述多于一个修复服 务器当中选择用于修复发往所述至少一个终端的分组的修复服务器；
以及重定向装置，用于将从终端接收到的、针对修复分组的请求重定 向至修复服务器，或者用于将请求转发至修复服务器。
以下阐述与所公开的实施例在范围上相当的特定方面。应当理解， 仅为了向读者提供本发明可能采用的特定形式的概要而提出这些方 面，并且这些方面并不意在限制本发明的范围。实际上，本发明可以 包含以下可能没有阐述的多种方面。
通过非限制性的以下实施例和执行示例，参照附图，将更好地理
解并示意本发明，附图中
-图1示出了具有单个服务器的系统的框-图2示出了根据实施例的多服务器架构的框-图3示出了根据实施例的修复控制器的框图；以及
-图4示出了根据实施例的选择方法的流程图。
在图3中，所示出的框是完全功能性实体，其不必与物理分离的
实体相对应。即，这些实体可以以硬件或软件的形式来开发，或者在一个或若干集成电路中实现。
具体实施例方式
示例实施例处于DVB-H架构中的视频广播的框架之内，但是本发 明并不限于该特定环境，而是可以应用于要在多个服务器上选择服务 器的其他框架内。
图1示出了具有单个服务器的系统。该系统遵循标准"ETSITS 102 472 VI .2.1 (2006-12) - Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content Delivery Protocols"。在IP网络(1)和DVB-H网 络(3)上向DVB-H终端(T1、 T2、 T3)广播内容(4)。终端通过遵 循GPRS标准的3G网络(2)向修复服务器(Rl)请求丢失的文件(5)。 修复服务器(Rl)对于文件服务器(Fl)来说是透明的。修复服务器 收听输出UDP业务并且应该是可靠的。修复服务器可以驻留在文件服 务器主机内。修复服务器可以是多信道的，即，修复服务器可以收听 与FLUTE会话相关联的若干ALC信道，ALC是在RFC 3450 -异步分层 编码(ALC)协议实例化中定义的。
FLUTE会话与文件传送会话相对应。FLUTE会话由传输会话标识 符(TSI)以及文件服务器的源地址来标识。在每一个FLUTE分组中 指示TSI。修复服务器可以专门用于收听唯一的会话，或者可以是多会 话的，即，修复服务器可以收听并行的若干会话。
当请求修复时，终端使用待修复的文件的统一资源标识符(URI)。 然而，接收器可能不知道该URI;承载URI与相应FLUTE传输标识符 之间的关联的FDT可能丢失。根据实施例，在文件的广播之后的文件 修复期间，可以使用正在进行的会话的传输对象标识符(TOO来唯 一地标识待修复的文件。TOI是嵌入FLUTE分组报头中的FLUTE协议 套标识符。可以在FLUTE会话的使用期限期间，在不同时刻重复使用 该标识符(作为与不同URI相关的传输对象标识符)。某时，在由于传 输会话标识符(TSI)以及发送方(即，文件服务器)的源地址IP而自 身标识的FLUTE会话内，该标识符通过FDT实例与有效URI唯一地相
关联时。FDT承载了与待传送的文件相关的、包括文件的URI在内的重要 信息。接收器使用FDT来相应地对文件进行存储、分类或处理。如果 已经部分地接收到FDT，则可能出现终端无法找到与接收到文件相关 联的任何FDT信息的情况。尽管FDT可以如上所述使用FLUTE标识符 来修复文件，并可以根据私有命名方案来存储该文件，但获得用于更 传统命名过程的丢失的FDT信息是有用的。根据实施例，已经如下扩 展修复请求终端可以请求FDT或至少请求与用对TSI/TOI标识的文件 相关的部分FDT。当然，优化后的请求收集用于标识文件的TSI/T01、 待修复的FLUTE分组的列表以及对同时获得关联的部分FDT的指示。
当前DVB-CBMS文件修复协议指定，请求修复的客户端发送与每 一个待修复的FLUTE分组相对应的FEC有效载荷ID。该FEC有效载荷 ID由源块编号(SBN)和编码符号ID (ESI)构成。修复服务器在其 响应中发回所请求的有效载荷组块的集合，每一个组块都被加有所谓 的FEC有效载荷ID作为前缀。这迫使客户端将输入的、已修复的分组 作为非FLUTE分组进行处理，或者迫使客户端重新组合FLUTE分组，
这不是件容易的任务。根据实施例，在收到客户端请求时，修复服务 器可以返回完整的FLUTE分组而不是仅返回有效载荷部分。这简化了 客户端侧的实施方式，这是由于当已修复的FLUTE分组来自DVB-H接 口时，可以将已修复的FLUTE分组再插入接收过程中。
图2示出了多服务器架构。其目的是给单个服务器系统提供可扩 縮性。多服务器架构包括根据FLUTE多播传送协议对文件进行广播或 多播的文件服务器(Fl)。
该架构包括通过可靠连接装置而与文件服务器相连接的至少一 个可靠修复服务器(RR)。可靠连接装置是提供非常低差错率或等于 零的差错率的装置。可靠修复服务器收听多播业务并同时构建其内部 文件数据库。可靠修复服务器在无任何差错的情况下获得所有业务。 在不同实体中表示可靠修复服务器和文件服务器。当然，它们可以位 于相同物理实体内。
该架构还包括一组非可靠修复服务器(Rl、 R2、 R3、 R4、 R5、 R6)，以下称作修复服务器。这些修复服务器捕获由文件服务器进行广播的文件。在这些修复服务器在有丢失和差错的情况下接收分组的 意义上，这些修复服务器是非可靠的。因此，这些修复服务器可能需 要与任意其他客户端终端一样使用文件修复协议来修复它们自己的文 件。
在IP网络(1)和DVB-H网络(3)上向DVB-H终端(Tl、 T2、 T3)广播内容。终端通过遵循GPRS标准的3G网络(2)，向修复控制 器(RC)请求丢失的文件。
该多服务器架构包括修复控制网关(RC)，其基本上是系统的 HTTP服务器前端。修复控制网关(RC)接收并分析来自客户端终端 的修复请求。修复控制网关(RC)根据修复服务器基础结构来决定修 复策略。在上述单个服务器系统中，可以将修复控制网关和可靠修复 服务器封装在一起。在多服务器架构中，可以在修复服务器之一中包 括修复控制网关。备选地，可以将修复控制网关与客户端终端并置。 通常，修复控制器有规律地轮询(poll)服务器，以检査哪个是活动 的或不活动的，并检査每一个服务器的CPU负载。
根据实施例，支持两种拓扑。
服务器农场基础结构(11)，也称作集中式基础结构，包括通过 LAN连接在一起的一组修复服务器。服务器农场由修复控制网关来控 制，并还可能与客户端直接互相连接。修复控制网关根据负载标准来 选择修复服务器，该负载标准与由用于执行基于DNS的负载平衡的网 络农场控制器所使用的负载标准相类似。
分布式基础结构(10)是为了提供最有效率的响应时间而沿着大 区域分布的一组修复服务器。
修复控制网关，也称作修复控制器，是系统基础结构的首端 (head-end)。其用于提交的地址是终端众所周知的仅有信息。当终端 需要修复文件时，终端向修复控制器发送修复请求。修复控制器可以 处理上述两种拓扑服务器农场和分布式网络。
在分布式网络的情况下，修复控制器将请求转发给与终端最接近 的修复服务器。转发是基于HTTP重定向的，其中，修复控制器向客户 端发回作为修复响应的HTTP重定向命令。在关于HTTP 1.0的RJFC1945和关于HTTP 1.1的RFC2616中定义了HTTP重定向。在接收到HTTP重 定向时，客户端向HTTP重定向中指示的修复服务器自动发布新的 HTTP请求。该修复服务器根据修复协议来响应该请求。
在服务器农场的情况下，修复控制器将请求转发给农场中负载较 少的修复服务器。将请求直接转发给修复服务器。所选修复服务器可 以根据修复协议来服务该请求。请求和响应始终经过修复控制器。
根据实施例，修复控制器不仅可以由于服务器负载少或者服务器 接近发送请求的终端而选择该服务器。修复控制器还可以选择能保证 与特定请求相关联的特定修复百分比的服务器。修复百分比是修复控 制器的配置参数。在该组修复服务器当中，依然存在被视为最可靠的 服务器。由于分组丢失，使得其他服务器可能部分地捕获到来自文件 服务器的完整业务。
如图4所示，如下对服务器进行选择。终端与修复控制器建立TCP 连接。在S1，终端向修复控制器发送HTTP修复请求。在步骤S2、 S3， 修复控制器修改该请求。为了指示该请求用于检查对于该修复服务器 来说修复是否可能，修复控制器改变该请求的名称。该请求不用于修 复。然后，修复控制器将该请求转发给最接近的修复服务器(当在分 布式网络中时)，或者转发给负载最少的服务器(当在服务器农场中 时)。换言之，修复控制器构建修复服务器的列表，并根据依赖于网络 类型的标准对列表中的修复服务器进行分类；在服务器农场中，分级 是基于服务器负载的。 在接收到请求时，修复服务器分析该请求，并向修复控制器发回 应答S4以指示其可确保的修复级别。可以基于如下若干参数来估计该
修复级别
-修复服务器可修复的文件的百分比(与关联的本地数据库中可 用的数据相对应)；
-与接收到的请求相对应的修复百分比。
修复控制器基于阈值，使用这些参数来决定其是否维持其选择。 如果修复服务器应答不满足修复控制器，则修复控制器尝试另一 个修复服务器S6，以检查其是否将提供更好的修复比率。如果该修复过程没有成功地提供修复服务器，则修复控制器使用
可能的负载标准来选择可靠修复服务器之一S7。
换言之，终端请求待修复的文件的特定数目的分组。在接收到请 求时，修复控制器向修复服务器发送请求，以了解服务器是否能够提 供分组。在接收到该请求时，服务器检查可用分组的数目。百分比是 可用分组的数目与所请求分组的数目之比。修复控制器设立阈值。如 果该百分比低于阈值，则修复控制器向另一服务器发送请求。如果该
百分比高于阈值，则选择该服务器。优选地，将阈值设置为值40%。
HTTP修复请求长度是有限的。可以将该长度限制为256字节的 值。如果终端请求大量数据，则单个请求是不够的，并且终端将若干 子请求连续发送至相同会话中。在这种情况下，修复控制器基于子请 求序列的第一个请求来对服务器进行选择。然后，修复服务器向每一 个子请求发送响应。
一旦选择了修复服务器，修复控制器的行为就依赖于基础结构。 在服务器农场的情况下，存在两种可能性。
在第一种可能性中，服务器农场与客户端的网络不直接相连。修 复控制器将请求转发给所选修复服务器，不是为了检查的目的，而是 为了处理的目的。修复服务器处理该请求并向修复控制器发回其应答， 该修复控制器将该应答转发回到终端，依此类推。
在第二种可能性中，服务器农场与客户端的网络直接相连。在接 收到修复请求时，修复控制器向客户端发回HTTP重定向命令。该命令 收集所选修复服务器地址。在接收到HTTP重定向时，客户端向HTTP 重定向中指示的地址处的修复服务器自动发送HTTP请求。修复服务器
向客户端发回修复分组，依此类推。
在分布式基础结构的情况下，仅第二种可能性适用。 可以将分布式基础结构与服务器农场基础结构相结合。结合后的
基础结构包括一组分布式"独立(standalone)"和"农场"服务器。
那么，控制器基于服务器(或服务器农场)的位置以及每一个单独修
复服务器的负载的级别，使用更复杂的启发式算法。
根据实施例，修复网关还包括单播-多播模块。该模块适于将修复模式从单播分发模式切换至多播分发。如上所述，网关将终端重定向 至修复服务器，或者将请求转发给修复服务器。这是单播模式。
采用遵循ETSITS 126 346的方式，网关可以将终端重定向至广播 /多播传送。当切换至多播时，网关优选地选择可靠修复服务器，该可 靠修复服务器将提供要通过该多播传送进行广播的修复数据。
图3示出了修复控制网关RC。修复控制网关RC包括连接至互联网 的通信装置102。当然，修复控制器可以连接至允许连接至修复服务器 和终端的任何其他类型的网络。通信装置使网关能够与终端和修复服 务器进行通信。
修复控制网关RC包括用于将来自终端的请求重定向至修复服务 器的地址的重定向装置104。根据实施例，重定向装置遵循如上所述的 HTTP重定向。
修复控制网关RC包括用于以上述方式选择修复服务器的选择装 置103。
修复控制网关RC包括用于如上所述在单播模式与多播模式之间 执行切换的单播-多播模块105。
修复控制网关RC包括以存储器形式存在的存储模块lOl，用于存
储该架构的修复服务器的列表。
修复控制网关RC包括以处理器形式存在的处理模块106。
可以将修复控制网关与计算机设备并置。当然，修复控制网关也 可以是包括此处所述的功能性模块的任意独立设备。
可以独立地或者以任意适当组合来提供说明书、权利要求以及附 图中公开的参考。可以以硬件、软件或者二者的组合来在适当处实现 特征。
此处对"一个实施例"或"实施例"的引用意味着，在本发明的 至少一个实施方式中可以包括结合该实施例进行描述的特定特征、结 构或特性。在说明书各处出现的短语"在一个实施例中"不必全部指 代相同的实施例，并且不必是与其他实施例互斥的单独或备选实施例。
出现在权利要求中的参考标记仅作示意之用，而不应该对权利要 求的范围有限制作用。
权利要求
1、一种系统中在修复控制设备(RC)处从多个修复服务器(RR、R1、R2、R3、R4、R5、R6)当中选择修复服务器的方法，在所述系统中，至少一个终端(T1、T2、T3)以及所述多个修复服务器收听以推模式从至少一个文件服务器(F1)分发的至少一个文件传送会话；所述方法包括以下步骤-从所述至少一个终端接收(S1)针对修复所述至少一个文件传送会话的分组的请求；-选择(S5、S7)用于修复发往所述至少一个终端的所述分组的修复服务器；以及-利用所选择的修复服务器的地址，将所述请求重定向至所述至少一个终端。
2、 根据权利要求l所述的方法，还包括以下步骤将来自所述终 端的、针对修复所述至少一个文件传送会话的分组的后续请求重定向 至所选择的修复服务器。
3、 一种系统中在修复控制设备(RC)处从多个修复服务器(Rl、 R2、 R3、 R4、 R5、 R6)当中选择修复服务器的方法，在所述系统中， 至少一个终端(Tl、 T2、 T3)以及所述多个修复服务器收听以推模式 从至少一个文件服务器分发的至少一个文件传送会话；所述方法包括 以下步骤-从所述至少一个终端接收(Sl)针对修复所述至少一个文件传 送会话的分组的请求；-选择(S5、 S7)用于修复发往所述至少一个终端的所述分组的 修复服务器；以及-将所述请求转发至所选择的修复服务器。
4、 根据权利要求3所述的方法，还包括以下步骤将来自所述终 端的、针对修复所述至少一个文件传送会话的分组的后续请求转发至 所选择的修复服务器。
5、 根据前述权利要求中任意一项所述的方法，其中，所述修复服务器是第一类型(RR)的或第二类型(Rl、 R2、 R3、 R4、 R5、 R6)的，其中第一类型的修复服务器仅正确地接收由所述文件服务器传输的分组的一部分，而第二类型的修复服务器正确地接收由所述文件服务器传输的所有分组，所述选择步骤包括以下步骤-对第一类型的修复服务器进行分类；-从所述分类的第一至最后一个修复服务器，相继地(S6)发送(S3)针对修复分组的请求，直到接收到(S4)具有指示的响应为止，所述指示是关于修复服务器能确保的修复的百分比的，其中所述百分比满足阈值；-如果修复服务器满足所述阈值，则选择该修复服务器(S5);以及-如果列表的最后一个修复服务器没有提供满足所述阈值的百分比，则选择(S7)第二类型的修复服务器。
6、 根据权利要求5所述的方法，其中，所述修复控制设备按照从负载最少到负载最多来对修复服务器进行分类。
7、 根据权利要求5或6所述的方法，其中，所述修复控制设备选择与请求设备最接近的第二类型的修复服务器。
8、 根据前述权利要求中任意一项所述的方法，其中，所述文件传送会话是基于单向传输的文件传送会话。
9、 根据权利要求3所述的方法，其中，所述选择步骤包括以下步骤-决定使用多播修复；以及-选择第二类型的修复服务器。
10、 一种修复控制设备(RC)，包括-通信装置(102)，用于在系统中与多于一个修复服务器以及至少一个终端进行通信，在所述系统中，所述多于一个修复服务器以及所述至少一个终端收听以推模式从至少一个文件服务器分发的至少一个文件传送会话；-选择装置(103)，用于在从所述至少一个终端接收到修复请求时，在所述多于一个修复服务器当中选择用于修复发往所述至少一个终端的所述分组的修复服务器；以及-重定向装置(104)，用于将从终端接收到的、针对修复分组的请求重定向至所述修复服务器，或者用于将所述请求转发至所述修复服务器。
全文摘要
本发明涉及一种修复控制设备以及在用于以下系统中、在所述修复控制设备处从多个修复服务器当中选择修复服务器的方法，在所述系统中，至少一个终端以及所述多个修复服务器收听以推模式从至少一个文件服务器分发的至少一个文件传送会话。所述方法包括以下步骤从所述至少一个终端接收针对修复所述至少一个文件传送会话的分组的请求；选择用于修复发往所述至少一个终端的分组的修复服务器；以及利用所选择的修复服务器的地址将所述请求重定向至所述至少一个终端，或者将所述请求转发至所选择的修复服务器。
文档编号H04N7/24GK101647282SQ200880010380
公开日2010年2月10日 申请日期2008年3月19日 优先权日2007年3月30日
发明者樊尚·阿洛姆, 纪尧姆·比绍 申请人:汤姆森许可贸易公司