因特网环境下综合负载分配和资源管理的系统和方法

1.一种请求管理系统，用于把来自独立客户机上的对多媒体对象 的请求放置到具有所述对象并分布在整个网络的服务器上，每个服务 器具有存储多媒体对象以及向客户机提交所请求的多媒体对象信息 流资源的能力，此系统包括：
中间控制装置，用于接受来自上述客户机上的对所说多媒体对 象的放置查询，请求的对象具有与其相关联的唯一标识码；
用于放置对象副本的装置，对象副本与给定的对象标识符相关 联，并存储在一个或多个所说的服务器上；
用于确定任何这种服务器对所说的对象副本放置查询进行考虑 的意愿的装置；以及
用于按照预定策略产生一个或多个放置查询到有意愿的服务器 上的装置，所说的中间控制装置发出一放置查询到所说的有意愿的服 务器上。
2.按照权利要求1的系统，其中所说用于放置对象副本的装置包 括第一目录服务装置，第一目录服务装置包含对象标识符与所说服务 器上同对象副本相关的位置的映射。
3.按照权利要求2的系统，其中所说用于确定服务器意愿的装置 包括第二目录服务，用于可用的分布式服务器与指示各个服务器接受 放置查询意愿程度的指示器之间的映射。
4.按照权利要求3的系统，其中所说的第二目录服务允许分布式 服务器与指示所说服务器上资源可用量的可用能力级别指示器之间 的映射。
5.按照权利要求4的系统，其中所说的控制装置实施放置策略， 以产生一个或多个试探性放置请求给服务器，所说的控制装置访问所 说的第一和第二目录服务，以确定所说的试探性放置。
6.按照权利要求5的系统，其中所说的预定策略包括一会话策略， 所说的控制装置还选择一个或多个试探性放置，并与各个相关服务器 会话，以允许按照预定准则在此服务器上放置特定请求。
7.按照权利要求6的系统，其中所说的预定准则包栝下列组中的 一个或多个选择项：信息流对象的分辩率，价格，信息流对象的质量， 客户机和服务器之间的距离，以及接收信息流对象的最大延时。
8.按照权利要求6的系统，其中所说的控制装置还实现探测策略， 以重复地测定在一个或多个服务器上多重放置的机会。
9.按照权利要求6的系统，其中所说的控制装置还包括监控在限 定时间间隔中接收的请求数，并按照一个或多个准则把上述请求集合 成请求组的装置。
10.按照权利要求9的系统，其中在有限时间间隔中集合需求请 求的预定准则包括请求相同对象标识符的客户机在地区上的接近度。
11.按照权利要求10的系统，其中在限定时间间隔中集合需求 请求的预定准则包括对相同对象标识符的请求信息流限制，包括对分 辩率和质量限制的共同性。
12.按照权利要求10的系统，其中在限定时间间隔中集合需求 请求的预定准则包括对相同对象标识符的请求的到达时间在时间上 的接近度。
13.按照权利要求12的系统，其中所说的控制装置还包括利用 多点传送能力提交一组类似的请求给服务器的装置，所说的服务器为 客户机提供多点传送服务。
14.按照权利要求12的系统，其中所说的控制装置还包括自动 地提升或降低一特定请求的装置以实现集合。
15.按照权利要求14的系统，其中所说的提升或降低特定对象 请求的装置进一步配置为分别减少或增加地理位置相近性分组准则 的敏感度。
16.按照权利要求14的系统，其中所说的提升或降低特定对象 请求的装置进一步配置为分别增加或减少请求对象的质量。
17.按照权利要求14的系统，其中所说的提升或降低特定对象 请求的装置进一步配置为改变时间相近性分组准则的敏感度。
18.按照权利要求9的系统，其中每个所说的服务器向所说的控 制装置报告其可用的系统能力。
19.按照权利要求9的系统，其中所说的控制装置还包括产生对 象副本，并按照对所说对象当前需求请求，动态地控制在服务器上放 置对象副本的装置。
20.按照权利要求19的系统，还包括根据以往对所说对象的需 求，为对象请求预报未来需求的装置，所说的对象副本的放置是根据 预报的需求确定的。
21.按照权利要求3的系统，其中所说目录服务的意原指示器表 示工作在所说分布式网络上服务器的主动性程度，所说的指示器用以 反映所说服务器主动性。
22.按照权利要求3的系统，其中在所说分布式网络上的服务器 包括包含一个或多个按单入口可寻址的服务器设备的服务器簇。
23.按照权利要求1的系统，还包括动态控制所说网络上可用对 象资源量的装置，所说动态控制装置包括：
预测对象资源的需求的装置；
监视上述网络中所说服务器在存储及提交请求的对象资源信息 流的能力的装置；以及，
根据对所说对象资源预测的需求和所说的可用能力，动态产生上 述对象资源的一个或多个对象副本，并且当需求预测增长时，在整个 所说网络的服务器上自动地暂时放置上述对象副本，当需求预测降低 时则删除副本的装置。
24.按照权利要求23的系统，其中所说的预测装置包含分析来 自不同客户机集合的请求，包括对请求的对象资源需求的密度和需求 量特性的装置。
25.按照权利要求24的系统，还包括按照预定准则管理动态放 置副本的装置。
26.按照权利要求25的系统，还包括触发检查的装置，以将可 用能力与针对特定请求对象预测的需求进行比较，所说的检查用来初 步确定指示需求超出能力的低能力条件，或指示能力超出需求的超能 力条件的可能。
27.按照权利要求26的系统，其中所说的生成装置包括放置具 有所说复制对象的源服务器，和放置所说对象副本的目标服务器的装 置。
28.按照权利要求27的系统，还包括用于会话复制选项，包括 规定在源服务器和目标服务器之间的复制连接，和复制所说对象时信 息流速率的装置。
29.按照权利要求28的系统，其中所说的复制对象具有相关联 的截止期，如果对所说对象低能力条件存在，所说的截止期延长；否 则，当所说的截止期限达到时，则删除所说的对象副本。
30.一种对分布在整个网络上的一个或多个服务器上存储的多 媒体对象形成需求的方法，每个服务器设备具有存储多媒体对象以及 向客户机提交所请求的多媒体对象的信息流资源的能力，此方法包 括：
接受来自独立客户机的对所说多媒体对象的请求，每个请求的对 象具有与其相关联的唯一标识码；
放置与请求的对象标识符关联的对象副本，这些副本存储在一个 或多个所说服务器上；
确定任何这种服务器对与所说对象副本的请求相关的放置查询 进行考虑的意愿；以及
按照预定策略为所说的对象产生一个或多个放置查询到有意愿 的服务器上，以及转送一放置查询到所说的有意愿的服务器上。
31.按照权利要求30的方法，还包括对象标识符与所说服务器 上对象副本的相关位置映射的维护步骤。
32.按照权利要求30的方法，其中确定服务器意愿程度的步骤 包括实现目录服务，以建立指示各个服务器接受放置查询意愿程度的 指示器与可用的分布式服务器的映射。
33.按照权利要求30的方法，其中确定服务器意愿程度的步骤 包括实现目录服务，以建立指示所说服务器上可用资源数量的可用能 力等级指示器与分布式服务器的映射。
34.按照权利要求30的方法，还包括维护与每个分布对象有关 的需求统计的步骤，所说的需求统计包括需求密度，需求量的性能， 及包括指示需求支配区域的地区指示器。
35.按照权利要求34的方法，其中所说的按照预定步骤包括选 择一个或多个试探性放置，并与各个相关服务器会话，以允许按照预 定准则在此服务器上放置特定请求的步骤，所说的预定准则包栝下列 组中的一个或多个选择项：信息流对象的分辩率，价格，信息流对象 的质量，客户机和服务器之间的距离，以及接收信息流对象的最大延 时。
36.按照权利要求34的方法，还包括监控在限定时间间隔中收 到的请求数，并按照一个或多个预定的特征把上述请求集合成请求组 的步骤。
37.按照权利要求36的方法，还包括为实现集合，自动地提升 或降低一特定请求的步骤。
38.按照权利要求30的方法，还包括动态控制所说网络中服务 器上对象资源数量的步骤，所说的动态控制步骤包括以下步骤：
预测对象资源的需求；
监控所说网络上服务器的能力，所说的能力包括存储对象资源和 向客户机提交对象信息流的能力；
复制步骤，用于当对所说的对象资源的预测需求超过所说的可用 能力时，复制所说的对象资源，并在位于所说网络中的服务器上临时 放置所说的对象副本；及
删除步骤，用于当对所说的对象资源的预测需求减少时，删除已 被临时放置的对象副本。
39.按照权利要求38的方法，其中所说的预测步骤包含分析来 自不同客户机集合的请求，包括对请求对象资源的需求密度和需求量 特性。
40.按照权利要求38的方法，还包括按照预定的价格准则管理 对象副本放置的步骤。
41.按照权利要求38的方法，其中在所说的复制步骤c)之前起 动一检查步骤，将可用的能力同请求对象的预测需求进行比较，所说 的检查用来初步确定表示对所说请求对象的需求超出能力的低能力 条件的可能。
42.按照权利要求41的方法，其中在所说的删除步骤之前起动 一检查步骤，将可用的能力同请求对象的预测需求进行比较，所说的 检查用来初步确定表示能力超出需求的超能力条件。
43.按照权利要求42的方法，其中所说的复制步骤还包括放置 具有被复制对象的源服务器和要放置所说对象副本的目标服务器的 步骤。
44.按照权利要求43的方法，其中所说的复制步骤还包含会话 复制选项的步骤，包括规定在源服务器和目标服务器之间的复制连 接，以及复制所说对象时信息流的速率。
45.按照权利要求38的方法，其中所说的复制步骤还包括给每 个复制对象分配一个截止期的步骤，所说的方法包括当其相关的期限 期满时，删除对象副本的步骤。
46.用于在因特网环境中对多媒体对象资源进行实时管理的集 成系统，该环境中具有用于存储和向客户机提供多媒体对信息流的服 务器，所述系统包括：
根据需求统计和服务器需求请求位置地理的相近性，用于监控对 对象资源的需求及预测对象未来需求的装置；
用来测定服务器设备在所说因特网环境下为提交对象资源信息 流，存储和分配资源的当前意愿的装置；
根据所说的需求统计，所说的当前意愿和所说的服务器需求请求 位置地理的相近性，在所说因特网环境下形成对象资源能力的装置， 所说的形成装置包括复制与所说对象资源有关的对象的装置，及临时 把所说的对象副本放置到具有可用的能力，在预测的地理需求位置上 的一个或多个服务器设备上的装置；以及
放置从客户机接收的对象资源请求输入，并生成及转送与一个或 多个接收的请求有关的放置查询到所说的地理位置上具有所说请求 对象资源的服务器设备上的装置。
47.按照权利要求46的集成系统，其中所说的形成能力的装置包 括根据与所说需求有关的特性，评估对象副本的数量和地理位置的装置。
48.按照权利要求46的集成系统，其中所说的用来放置接收的 请求输入的装置包括根据某些策略询问对于输入一个或多个请求，服 务器的意愿和能力的装置。
49.一种用以动态控制分布式网络服务器上对象资源数量的系 统，每个服务器具有存储和提供所说对象资源信息流给用户的能力， 所说的系统包括：
a)预测对象资源需求的装置；
b)监视在所说网络上所说服务器为存储和提供请求的对象资源 信息流的能力的装置；以及
c)实现如下功能装置，用于根据对所说对象资源预测的需求和 所说可用的能力，产生一个或多个所说对象的副本，并且当预测需求 增加时，自动在整个所说网络的服务器上临时放置对象副本；当预测 需求减少时，则删除副本。
50.一种用以动态控制分布式网络服务器上对象资源数量的方 法，每个服务器具有存储和提交对象资源信息流的能力，所说的方法 包括：
a)预测对象资源的需求；
b)监控所说网络上服务器的能力，所说的能力包括存储对象资源 及向客户机提交对象信息流的能力；
c)当所说对象资源的预测需求超过所说的可用能力时，复制所说 的对象资源，并暂时在位于所说网络中的服务器上放置所说的对象副 本；及
d)当所说的对象资源的预测需求减少时，删除已暂时放置的对象 副本。
51.按照权利要求50的方法，其中所说的预测步骤包含分析来 自不同客户机集合的请求，包括对请求对象资源的需求密度和需求量 特性。
52.按照权利要求50的方法，还包括按照预定价格准则管理对 象副本放置的步骤。
53.按照权利要求50的方法，其中在所说的复制步骤c)之前起 动一检查步骤，将可用的能力同请求对象的预测需求进行比较，所说 的检查用来初步确定表示对所说请求对象的需求超出能力的低能力 条件的可能。
54.按照权利要求53的方法，其中在所说的删除步骤d)之前起 动一检查步骤，将可用的能力同请求对象的预测需求进行比较，所说 的检查用来初步确定表示能力超出需求的超能力条件。
55.按照权利要求54的方法，其中所说的复制步骤c)还包括放 置具有复制对象的源服务器和要放置所说对象副本的目标服务器的 步骤。
56.按照权利要求55的方法，其中所说的复制步骤c)还包含会 话复制选项的步骤，包括规定在源服务器和目标服务器之间的复制连 接，以及复制所说对象时信息流的速率。
57.按照权利要求55的方法，其中所说的复制步骤c)还包括给 每个复制对象分配一个截止期的步骤，所说的方法包括当其相关的期 限期满时，删除对象副本的步骤。
58.按照权利要求57的方法，还包括当所说的对象存在低能力 情况时，延长所说的截止期的步骤。
59.按照权利要求56的方法，其中所说的复制步骤c)还包括按 照会话选项传送所说的对象副本的步骤。
60.按照权利要求50的方法，还包括在所说的分布式网络上跟 踪每个对象状态的步骤，所说的状态包括存储有请求对象的服务器的 当前位置及身份。
61.按照权利要求50的方法，其中所说的监控步骤b)包括在 所说的服务器、客户机、和控制器设备之间实现信令协议的步骤，以 允许所说的服务器去控制动态放置对象副本到所说的服务器上。

技术领域\n本发明总的涉及在广域计算机网络环境下，监视、控制和分配资 源需求的各种技术，尤其是涉及一种新的在Web和多媒体服务器上 分配负载以及在多个Web和服务器上管理和分配资源的方法。\n背景技术\n图1描述了一种典型的分布式计算机系统10，它由多个客户机 (110、111、112)、多个服务器(120、121、122)和多个相互独立的 对象集合体(130、131、132)所组成。这些组成部分之间由计算机 网络环境160连接起来。因此，可以使客户机(如：111)直接对服务 器上的一个或多个对象发出请求消息140。系统使这种服务器端(如： 121)建立信息流连接150。然后将对象信息发送到发出请求的客户机 (如：111)。这种计算机网络环境就是典型的因特网环境。这里的浏 览器代表客户机、Web服务器代表服务器、Web网站代表对象集合体， 因特网代表计算机网络环境。我们都知道，HTTP协议能使客户机通 过被称为是统一资源定位器(URL)的地址边界标识符从给定的服务 器请求一对象。传输控制协议(TCP协议)能将一信息流对象(如： 一个网页或一个视频影像文件)从Web服务器传送到客户机。\n图2更详细地描述了图1中所述的环境下的服务器(如：120)的 各组成部分。它包括了内存(210)、中央处理器CPU(220)、硬盘(230) 和网络带宽(240)等有限量的本地资源(200)。服务器与一系列的 对象集合(130)有关。此处的集合由四个对象(281，282，283，284) 所组成。由服务器端的服务逻辑元件(250)来控制与客户机间的交 互作用，如录像机在播放节目(如：暂停、倒带、停止、进带等)、 记帐和安全性等方面的交互作用。信令协议(261)(如：HTTP)能 使服务器接收来自客户机的请求(如：140)。对于要从服务器的对象 集合体中获取对象的客户机(如111)，服务器把它的部分资源(200) 分配给相应信息流连接(150)。因为资源是有限的，一个接纳控制处 理(260)用来判断是否输入的请求能适用。本地资源管理处理(270) 用来保存、存取、监控和重分配服务器中的资源(200)(如图2中所 示的硬盘(HDD)、带宽(B)、中央处理器(CPU)、内存(MeM) 等)。网络信息流处理(275)依靠信息流协议(271)通过向客户机 建立和管理信息流连接(如150)，将信息传送到它的客户机。任何一 台特定服务器(如：120)上的资源管理完全与任何其它的特定服务 器(如：121)的资源管理无关。此外，不同服务器上的对象集合体 (如：130和131)间也相互独立。而且，即使是同一对象(如：对 象‘04’)的副本(如：281，285)，因为它们可存在不同服务器上的两 个不同对象集合体(如：130，131)中，所以也无法建立两个对象副 本(282，285)间的相互联系。\n如图3所示，分布式计算机系统10(见图1)，可使用对象目录服 务300，配备对象请求代理程序ORB为对象的集合体(如：130，131， 132)提供目录服务，从而扩大了客户机(如：110，111，112)从分 布对象集合体(如：130，131，132)中请求对象(如：媒体内容文 件04)位置的透明度。对象目录服务机构300提供了在整个计算机网 络环境(160)中放置任何一个对象所需的信息。目录310专门跟踪 与对象有关的服务器。例如：其中的第一条目录表示对象281建立在 服务器120上，而第二条目录表示对象285建立在服务器121上。\n随着下一代因特网，如因特网2的飞速发展，开展有效地利用广 泛分布在网络上的信息和资源工作将变得相当重要。第二代因特网工 作主要是发明一种适合于充分挖掘宽带网络潜力的新一代应用的先 进网络。高带宽网络和带宽储备将使得诸如连续数字视频和音频器材 从研究应用走向更广阔的实际应用成为可能，包括在某种程度上目前 不可能实现的图像、音频和视频等信息。在这种广域分布式网络环境 下，对其中的资源进行负责地、有效地和自动调节的管理是希望的、 也是最重要和必要的。\n丰富的多媒体信息的商业化是因特网向下一代因特网发展的推 动力。公司生产的数字库集合、电影演播室提升成娱乐素材，及各大 学制作的交互式教学演示在不久都将会在因特网上得到利用，因此会 产生一种新的、广阔的收入源泉。\n新一代因特网依赖于网络带宽，这种带宽约为几倍于现在的因特 网提供的带宽。并且通过引入相应的监控机制来缓解网络资源的管理 和QoS控制。但是，到目前为止，这种能对多个媒体连接集中管理、 在广域网环境下通过多个服务器，用有效方法共享资源的机理还未找 到。\n那些新出现的成功的商业化应用，需要三个主要条件：第一，需 要提供机制，以允许让用户和网络服务提供商建立合同，在双方相互 认可的价格下，以预定所需的网络基础设施和资源，提供建立和支持 有保证的服务质量。第二，所提供的网络资源必须充分满足各种随机 变化的需要，因为这些需要在体系结构研究中完全是不可预测的。第 三，服务提供商应安全地依靠系统来达到现行的安全性、权限管理、 特许权管理，和动态地可重新配置的分布式虚拟资源消耗的帐目管理 和帐单。\n在今天的因特网中，当前资源管理的重点涉及设置和管理各个独 立的媒体与服务器资源的连接。但是，当存在再使用多种原始资料的 内容时，这种方法的危险将变得明显。当再使用多种原始资料的内容 时，为了提高其需要的质量以及控制其使用和分布，两种方法是可能 的。一种方法是在创作过程中将所有内容拷贝到单一的服务器上(或 某一服务器簇)，并且根据预期需求将最后的结果复制到必要的多个 服务器上。然后，原始内容提供商将基于先验的市场分析建立版权收 费制度。从积极的方面看，对分布式控制、安全性和记帐功能比在分 布式内容的情况下要容易。从消极的方面看，如果需求估计不正确， 则对主要的或次要的(如：再使用)内容提供商来说，其利润不能达 到最大值。最后，最危险的问题是如果不中途禁止过多的请求的话， 这种方法将导致资源超出工程设计水平。这种方法对今天的因特网有 代表性，因为，与多媒体应用相比，当前的多媒体内容总的来说不会 造成存储紧张。\n另一种方法是，根据某种需要，为创作和传播重新汇集内容。这 将允许内容被存储一次但可据需要使用多次，建立对内容和资源的使 用的合适的收费制度，以及减轻对存储的要求。然而，这需要一个动 态管理很多且通常不同资源的系统。此外，这一方法使安全性和资源 设计工程量恶化。由于这些特殊部分的需求不能完全预测，因为这些 部分可用在完全不同处，甚至是互不相关地应用。现在，如果对某一 部分的需求不能满足的话，则多种应用将受到影响。然而，后一方法 是唯一可行的被将来的因特网所使用的方法，因为从资源的观点看， 它是最经济的，且能为最大数量的用户提供服务。\n因此，提供一种能满足所有三个主要商业条件的系统方法是高度 可取的。\n在QoS驱动的资源管理领域中有很多出版物和专利。其中大部分 集中在或者是网络领域，如：1995年2月7日授予Baugher，M.J.等 的美国专利5388097，题目是“System and Method for Bandwidth Reservation for Multimedia Traffic in Communication Networks”；及 1996年12月3日授予Baugher，M.J.等的美国专利5581703，题目 是“Method and Apparatus for Beserving System Resources to assure Quality of Service”中所述；或者是操作系统领域，如在参考文献“An Architecture Towards Efficient OS Support for Distributed Multimedia”，96年会刊“IS&T/SPIE Multimedia Computing and Networking Conference”，San Jose，CA，1996年1月由David K. Y.Yau和Simon S.Lam.中所述。随着因特网上的多媒体服务的激 增，立刻实现了用IP网络提供一种简单的、方便的传输服务，但IP 协议不适用于新的实时应用，如多媒体信息流、虚拟现实应用、分布 式的超大型计算。结果，新的网络协议，如：资源预订设置协议 (Resource Reservation Setup Protocol)(RSVP)(参见如：“The Grid：Blueprint for a New Computing Infrastructure”，由Ian Foster and Carl Kesselman编辑，第19章，第379-503页，1999年Morgan Kauffman发表)；实时传输协议(RTP)；实时传输控制协议(RTCP) 以及其它协议被提出(参见如：William Stallings，“High-Speed Networks：TCP/IP and ATM Design Principles”，Prentice Hall，1997； 以及I.Busse，B.Deffner，and H.Schulzrinne，“Dynamic QoS Control of Mulltimedia Applications based on RTP”，Computer Communications，1996年1月)，使应用能够请求和会话确定网络QoS 参数，如带宽和等待时间。那些协议在当今因特网上的发展并不成功， 首先因为它需要对所有非-RSVP的路由器和服务器系统软件进行升 级，其次，即使RSVP在当今的因特网上得以发展，相当有限的带宽 和计算资源仍然是实时应用成功发展的瓶颈。当今因特网建立在以相 对无阻塞的T3速率(每秒45兆位)进行跨国家通信的骨干上。图形 数据页的激增以及音频和视频信息流的应用相当快地耗尽了那些资 源。更糟糕的是，用户数量的增长率比最新建立的网络资源高得多。\n美国国家科学基金会(the National Science Foundation)和MCI 公司顺应因特网公众的需要，正在建立起一种新的网络，称为vBNS 网络(甚高性能基干网络服务)。这一国家范围的网络也为两个基金 会提供了主骨干网，被大学称为第二代因特网(因特网2)、被联邦 研究署称为新一代因特网。vBNS可使大量的研究机构相连，以每秒 622兆位的速度(OC12)工作，到2000年，vBNS被期待以每秒2.4 千兆(每秒2400兆位)的速度运转。\nvBNS系统利用RSVP协议支持两类不同的服务：预订带宽服务 即带宽委托服务，和传统的最有效的IP服务(参见如：Chuck Song， Laura Cunningham和Rick Wilder，“Quality of Service Development in the vBNS”，MCI公司，在 http：//www.vbns.net/presentations/papers/QosDev/ieeeqos.htm网址提 供)。在vBNS网络层的资源管理仍然和操作系统层分开，并且同应 用需求与最终资源的可利用性如：存储和计算资源分开。\n一些高性能应用的新品种正在涌现，如：远程手术、机器人、远 程仪器、紧急自动响音、卫星数据数字库、利用支持多媒体的Web 站点的远程学习、增强的音频以及视频。然而，为了适应这些高性能 的应用以及它们的连续媒体数据流的需要，增加或预订网络能力还是 不够的。这些新的应用需要端对端的资源预订和接纳控制，并伴随有 分布式功能的协调，如：(a)最终系统的资源调度(如：CPU，磁盘 等等)，(b)网络上的信息包调度和流控制，及(c)被传输的端对端 服务质量的监控。服务质量的可配置、可预知和可维护是必要的，这 包括终端系统设备、通信子系统和网络。此外，分布式系统结构的所 有端对端要素都必须协调工作以达到所期望的应用水平。\n到目前为止，在端对端服务质量支持方面的发展已取得了相当大 的成就。他们当中有：\nHeidelberg QoS模型l，是在IBM欧洲连网中心的Heiproject项 目中发表的，并在参考题为“HeiRAT-Quality of Service Management for Distributed Multimedia Systems”，Multimedia Systems Journal，1996，by Volg，C.，Wolf，L.，Herrtwich，R.and H. Wittig中叙述的；\n一可扩充的集成参考模型(an Extended Integrated Reference Model(XRM))，由哥伦比亚大学COMET组发表的，如在参考题为 “Building Open Programmable Multimedia Networks”，Computer Communications Journal，Vol.21，No.8，PP.758-770，June 1998 by campbell，A.T.Lazar，A.A.，Schulzinne，H.And R.Stadler中所叙述 的；\nOMEGA端点结构，由宾夕法尼亚大学的交叉学科研究发表的， 如参考题为“Design，Implementation and Experiences of the OMEGA End-Point Architecture”，Technical Report (MS-CIS-95-22)，University of Pennsylvania，May 1995 by Nahrstedt K.And J.Smith中所叙述的；\nin-serv体系结构受工程任务组(IETF)的影响，如参考题为“A Framework for End-to-End QoS Combining RSVP/Intserv and Differentiated Services”，因特网Draft，IETF，March 1998 by Bernet Y，等中所叙述的；\n服务器结构质量QoS-A，由A.Campbell发表，并提出了关端对 端QoS需求的集成框架结构，如参考题为“A Quality of Service Architecture”，PhD thesis，Lancaster University，January 1996 by Andrew T campbell中所叙述的。\n其他分析上述的QoS论文的参考文献，如参考题为“A Survey of QoS Architectures”，ACM/Springer Verlag，Multimedia Systems Journal，Special Issue on QoS Architecture，Vol.6，NO.3，pp.138-151， May 1998 by Aurrecoechea，C.，Campbell，A.T.And L.Hauw.\nSRI International已做出了有实质性的工作，发表了分布式系统 的端对端资源管理(End-to-End Resource Management of Distributed Systems)(ERDOS)，它能对分布式系统中的资源进行适合的、端对 端的、可升级的管理，如在参考文献ERDOS QoS Architecture， Technical Report，SRI International，May 1998中所述。\n可扩充资源说明语言(RSL)以及资源管理结构在Glous meta-computing toolkit中已实现，并被用于实现各种不同资源管理方 案如：在Czajkowski，K.等“A Resource Management Architecture for Metacomputing System”Proc.IPPS/SPDP’98 Workshop on Job Scheduling Strategies for Parallel Processing，1998；以及Foster，I.， Kesselman，C.，“The Globus Product：A Status Report”Proc. IPPS/SPDP’98 Heterogeneous Computing Workshop，pp.4-18，1998 中所述。\n尽管上述参考文献中所述的结构是直接的资源预订和对端对端 资源的管理，但它们一般都假定一个提供延迟范围、容错和满足带宽 要求的单一的、甚至地理上有限的网络子系统，以及能提供运行时 QoS担保的操作系统。而下一代因特网决不能被视为仅仅是网络的网 络，而首要是一种分布式系统的系统，在本范例中，不仅通信资源， 而且计算和存储服务器是在许多用户间共享的。\n因此，上面所述的结构不能对整个系统资源提供协调管理的功 能，如对个别内容和计算资源的请求激活功能。它管理预先指定给特 定服务的资源。所以，服务质量必须被降低以满足对这一超出设计限 制的服务不断增长的请求量。虽然上面所述的那些结构涉及由应用程 序请求时提供QoS，但由于各个用户对特定服务的请求间的共同特 性，它们并不利用资源的可能集合体。\n例如，确定特定多媒体内容的使用历史的共同特性将是可取的， 如：在某一很短的时间间隔内发出的请求数、请求的原始地址的相近 性等等。此外，上面所述的结构不允许为了计算对个别客户机服务的 价格而动态监控和记录单个服务以及相关服务组的资源消耗。\n发明内容\n因此，能为分布式资源提供适合的资源管理功能的机理将是高 度可取的，它能根据需求，环境的需要形成系统能力，这种机制适合 于下一代因特网。\n此外，提供能综合能力形成机制也是希望的，这些机制通过广泛 分布的多媒体服务器的集合，具有管理和驱动负载分配的能力。\n本发明提供了管理多媒体内容和资源的系统和方法，用来开拓未 来计算机网络环境的独特特点。\n根据本发明的一个方面，提供一种请求管理系统，用于把来自独 立客户机上的对多媒体对象的请求放置到具有所述对象并分布在整 个网络的服务器上，每个服务器具有存储多媒体对象以及向客户机提 交所请求的多媒体对象信息流资源的能力，此系统包括：中间控制 装置，用于接受来自上述客户机上的对所说多媒体对象的放置查询， 请求的对象具有与其相关联的唯一标识码；用于放置对象副本的装 置，对象副本与给定的对象标识符相关联，并存储在一个或多个所说 的服务器上；用于确定任何这种服务器对所说的对象副本放置查询进 行考虑的意愿的装置；以及用于按照预定策略产生一个或多个放置查 询到有意愿的服务器上的装置，所说的中间控制装置发出一放置查询 到所说的有意愿的服务器上。\n根据本发明的一个方面，提供一种对分布在整个网络上的一个或 多个服务器上存储的多媒体对象形成需求的方法，每个服务器设备具 有存储多媒体对象以及向客户机提交所请求的多媒体对象的信息流 资源的能力，此方法包括：接受来自独立客户机的对所说多媒体对象 的请求，每个请求的对象具有与其相关联的唯一标识码；放置与请求 的对象标识符关联的对象副本，这些副本存储在一个或多个所说服务 器上；确定任何这种服务器对与所说对象副本的请求相关的放置查询 进行考虑的意愿；以及按照预定策略为所说的对象产生一个或多个放 置查询到有意愿的服务器上，以及转送一放置查询到所说的有意愿的 服务器上。\n根据本发明的一个方面，提供用于在因特网环境中对多媒体对象 资源进行实时管理的集成系统，该环境中具有用于存储和向客户机提 供多媒体对信息流的服务器，所述系统包括：根据需求统计和服务器 需求请求位置地理的相近性，用于监控对对象资源的需求及预测对象 未来需求的装置；用来测定服务器设备在所说因特网环境下为提交对 象资源信息流，存储和分配资源的当前意愿的装置；根据所说的需求 统计，所说的当前意愿和所说的服务器需求请求位置地理的相近性， 在所说因特网环境下形成对象资源能力的装置，所说的形成装置包括 复制与所说对象资源有关的对象的装置，及临时把所说的对象副本放 置到具有可用的能力，在预测的地理需求位置上的一个或多个服务器 设备上的装置；以及放置从客户机接收的对象资源请求输入，并生成 及转送与一个或多个接收的请求有关的放置查询到所说的地理位置 上具有所说请求对象资源的服务器设备上的装置。\n根据本发明的一个方面，提供一种用以动态控制分布式网络服务 器上对象资源数量的系统，每个服务器具有存储和提供所说对象资源 信息流给用户的能力，所说的系统包括：a)预测对象资源需求的装置； b)监视在所说网络上所说服务器为存储和提供请求的对象资源信息 流的能力的装置；以及c)实现如下功能的装置，用于根据对所说对 象资源预测的需求和所说可用的能力，产生一个或多个所说对象的副 本，并且当预测需求增加时，自动在整个所说网络的服务器上临时放 置对象副本；当预测需求减少时，则删除副本。\n根据本发明的一个方面，提供一种用以动态控制分布式网络服务 器上对象资源数量的方法，每个服务器具有存储和提交对象资源信息 流的能力，所说的方法包括：a)预测对象资源的需求；b)监控所说 网络上服务器的能力，所说的能力包括存储对象资源及向客户机提交 对象信息流的能力；c)当所说对象资源的预测需求超过所说的可用 能力时，复制所说的对象资源，并暂时在位于所说网络中的服务器上 放置所说的对象副本；及d)当所说的对象资源的预测需求减少时，删除 已暂时放置的对象副本。\n具体地，本发明的目的是提供一种在因特网/全球网环境下管理和 控制资源的分布、共享和组合的系统和方法。本发明在客户机和服务 器间实现了一个中间控制结点，用于按照一组准则，管理服务器上多 媒体对象请求的分布和放置，以及管理在服务器上对象的放置。\n本发明的还有一个目的是提供在因特网/全球网环境下管理和控 制资源的分布、共享和组合的系统和方法，它包括使对(多媒体) Web对象的预期需求与Web服务器上的可用能力相匹配，并且通过 以下方法动态地为多媒体对象形成需求和多媒体Web服务器的能力： (a)控制与有关对象的副本数量；(b)控制这些副本的位置。\n因此，按照本优选实施例，一个在分布式计算机环境下，提供集 成负载分布和资源管理功能的自治的自调节的系统被提供。该系统使 预期需求与可用能力相匹配，并且在追踪这一对象的过程中，按照某 些准则，提供形成需求和能力的机理。\n本发明的另一目的是提供一种在因特网/全球网环境下，管理和控 制能供给多媒体内容资源的分布、共享和组合的系统和方法，在这种 方式下，对用户来说是有益的、负有责任的和无缝连接的。\n按照本发明的原理，在客户机(如：Web浏览器)和服务器(如： 媒体/Web服务器)间提供了一个中间控制结点(控制器)，用于管理 在服务器上请求的分布和放置，以及管理服务器上内容的放置。该控 制器担任了中间者的角色，以接收请求并按某些准则对这些请求制订 放置信息。为此，该控制器代表客户机探测、会话及为客户向服务器 推荐请求位置。\n系统依靠该控制器对媒体/Web服务器上的分布式对象集合体进 行管理。在本发明的上下文中，资源管理是指预订、配置、控制、例 外处理，以及用于有效地为客户机提供多媒体内容的资源发放。\n特别地，该控制器试图使对对象(到一个或多个服务器上)的预 期集中需求与服务器上的可用能力相匹配。为此，预期需求统计值是 通过到达该中间控制结点的集成请求信息流的分析得到的，而可用能 力是通过在服务器和该控制结点间的专门协议粗略估计的。该控制器 依靠能力形成机制来动态控制服务器上的对象的位置和数量。\n此外，本发明依靠两个互补概念：用于提供备用的、可共享的和 高度可用能力的全局服务器；及模仿多媒体对象的临时副本，作为可 升级的和可重新放置响应需求和能力情况的资源。它们一起提供一个 系统，该系统可用于帮助一多媒体服务器，通过暂时增加整个系统能 力来匹配和某一特定的多媒体对象有关的预期需求。这些互补的概念 另外还用于提供一种系统和方法，以动态控制因特网环境下副本的位 置和数量，响应需求和能力间的约束，因此，本发明的系统提供了有 效的的方法，去监控需求和能力，并且确定何时去增加临时副本以及 从何处删除临时副本，即形成全局服务器的能力。特别地，“根据需 要”复制对象作为一种工具，用于在对同一个对象的随后请求进行处 理时，增加查找可用副本的可能性。\n重要的是必须指出，本发明成功地实现了以上功能，同时还保持 了各服务器对它们的资源的自治。资源管理系统被分散，那就是资源 管理控制(如：接纳控制、资源预订、资源量测、资源调度等)在每 一服务器本地实现，而不在控制器端集中。控制器不直接管理服务器 和它们的资源。相反地，控制器代理向服务器发送控制建议。其达到 的目的并不是强调控制器就资源状态和网络服务器进行严励监视。在 服务器和控制器间的信令协议允许控制器在运行期间以容错的方式 维持资源管理状态。该系统以信令开销换取状态维持开销。\n附图说明\n本发明的设备和方法的更多的特点、状况及优点，根据以下的说 明、所附的权利要求书和附图，将变得更易理解，其附图为：\n图1描述了由客户机、服务器和存储在服务器上的可以被客户机 访问的对象集合体所组成的典型的分布式计算机系统。\n图2更详细地描述了图1中所涉及的一个典型的分布式计算机系 统的服务器设备的组成部分。\n图3描述了一个典型的分布式对象系统，它包括了一个对象请求 代理程序系统，使能放置和管理分布式集合中的任何一个对象。\n图4按照本发明的优选实施例，描述了一个分布式计算机系统 (100)，包括一个用于控制客户机请求的中间控制器装置。\n图5描述了控制器的主要组成框图。\n图6(a)描述了一个副本目录例(666)，包括有关副本目录的图 表和数据。\n图6(b)描述了一个服务器目录例(656)，包括有关服务器目录 的图表和数据。\n图7通过一个例子，描述了放置管理协议的活动时间图。\n图8描述了动态地控制副本放置到全局服务器上的一个分布式计 算机系统，这里的需求和地区趋向被用于帮助区别持久副本和临时副 本。\n图9(a)描述了一特定的三色水印方案，所用方案通过服务器结 合它的利用状态转成常规的服务意原指示信息，使控制器能跨接所有 的服务器使用。\n图9(b)显示了在不同服务器上采用相同水印方案的应用。\n图10中更详细地描述了按照发明的服务器装置的修改情况。\n图11(a)中描述了控制器所观测到的一系列请求信息流，以及 为产生需求统计信息使用的有限时间间隔。\n图11(b)，通过一个例子描述了在优选实施例中用的方法，以对 图11(a)中所示的请求信息流生成地区密度指示。\n图11(c)通过一个例子描述了通过对应于图11(a)和11(b) 的控制器，来存储需求统计信息。\n图12描述了副本管理处理及基于触发式与请求管理系统的交互 的高级图。\n图13(a)是一流程图，它描述了由请求管理系统所实现的预先 过剩检查，以激活容量调整机构(即：副本管理系统)。\n图13(b)是一流程图，它描述了由请求管理系统所实现的预先 不足检查，以激活能力形成机制。\n图14是一描述副本创建处理的流程图。\n图15是一描述副本放置处理的流程图。\n图16是一描述副本删除处理的流程图。\n图17是一描述在本优选实施例中所用的需求对供应检查的流程图。\n图18描述了复制管理协议的活动时间图。\n具体实施方式\n图4说明了按照本发明的优选实施例的一个分布式计算机系统 (100)，它由客户机(110，111，112等)、服务器(1201，1211，1221)、 对象集合体(130，131，132)和客户机发出的对象请求500组成。 如图4所示，该分布式计算机系统还包括了一个中间控制器(520)， 用于处理由客户机所发出的请求。中间控制器(520)根据下文将描 述的一系列准则，从客户机(如111)把请求(如：501)发到服务器 (如：1211)。例如，在优选实施例中，控制器采用负载平衡和容错 方法，经分布式对象集合体(130，131，132)，放置为客户请求。此 外，正如在此将详述的，中间控制器按某些系列准则，管理各多媒体 对象自身放置到服务器上。\n正如在此将进一步解释的，中间控制器(520)提供方法，具体 地，对象目录服务机构，如ORB提供的方法，使系统100的特性具有 与服务器集合相反的分布式对象集合。因此，不象现有系统(10)， 在各个相互独立的服务器上(1201，1211，1221)上，寻找各种对象 集合体(130，131，132)，而根据需要和能力条件，当时集合成模仿 多媒体对象的对象和对象副本的分布式集合(130，131，132)，作为 可升级和重新放置的资源。例如，图4中说明了与对象(04)有关的 各对象副本(281，285)，其中一个副本存在服务器1201的对象集合 (130)中，而另一个副本存在服务器1211的对象集合(131)上。 正如在此要详述的那样，保存持久对象副本的服务器可以称为本地服 务器，而保存临时对象副本的服务器称为全局服务器。全局服务器用 于提供备用的、可共享的和高度可利用的能力，以保存大量的临时对 象副本信息。\n按照本发明，呈现在控制器(520)上的临时的客户机请求序列 称为请求信息流或需求。一个成功的客户请求(如：140)产生一个 信息流连接(如150)(在此也称为信息流)。设对某些多媒体对象给 出一特定的请求，通过给出的可用资源服务器可形成同时发生的信息 流的数量，在此称为多媒体服务器的可用能力。而且，通过控制器520 可以知道，信息流(请求的多媒体对象)数量的大小，可得到当时整 个系统支持，在此也称为可用的系统能力。特别地，在优选实施例中， 统计量度被用来高效地在一个分布式式环境的广域网络中，就像期望 的因特网2那样粗略评价可用能力。\n应该指出的是，在全球信息网(World Wide Web)上，用于控 制多媒体信息流数据的标准，如H.323和实时信息流协议(RTSP)， 已在应有的位置，并且实现了预期提供信息流的能力。如H.323用在 小单位内的电视会议上，而RTSP用于在大集团内有效地传送音频和 视频数据。每种标准都描述了客户机—服务器在应用层上的协议，以 控制实时性质数据的传送。如RTSP用于实现和控制一个或多个时间 同步的连续媒体信息流，如音频和视频数据，及利用传输协议，如 UDP、多点传送UDP，TCP，和实时协议(RTP)去传送连续信息 流。\n图5是中间控制装置(520)的详细框图，该控制器用于实现管 理服务器上请求(如多媒体对象的请求)的分布和放置，同时管理各 服务器上的多媒体对象自己的位置。如图5所示，一个请求处理模块 (600)用于接收各客户机发来的请求(601，602，603，604)，这些 请求包含了一个唯一的对象标识符，并把这些请求传送给放置模块 (610)。放置模块(610)为每一请求提供一放置策略(615)，并为 请求产生一系列的试探性的放置查询(620)。特别指出，放置模块 (610)既与副本目录服务机构(665)(用于保存副本目录(666)， 在此请参照图6(a))又与服务器目录服务机构(655)(用于保存服务 器目录(656)，在此请参照图6(b))相联系，形成试探性位置。也 就是说，放置模块(610)、副本目录服务机构(665)和副本目录(666) 管理与接收请求的对象标识符有关的所有副本的位置。此外，正如下 文中将说明的，放置模块(610)、服务器目录服务机构(655)和服 务器目录(656)联合确定任何这种放置(保存的副本)的意愿，以 考虑新的放置查询(620)。\n图6(a)描述了由副本目录服务机构(665)保存的副本目录(666) 的例子，包括本发明中的分布式计算机系统(100)中所实现的有关 副本目录的结构和数据。为了唯一地标识整个分布式集合中的一个对 象，赋予分布式集合中每一个不同的对象(如04等)一个对象标识 符。根据本发明，原始的客户请求可被一个辅助系统(未显示出)进 行预处理，辅助系统能把客户机发出的不明确的请求转换成具有唯一 可标识的对象标识符。对于每一对象标识符，整个分布式集合中可能 存在一个或多个副本。如在图6(a)中，有两个不同的对象标识(420， 440)。然而第一个对象标识符(420)与当前两个对象副本相关，第 二个对象标识符(440)只与一个副本(441)相关。具有同一个对象 标识符的副本被分布在不同的服务器上。如：对象标识符(420)的 副本(如421，422)分别存在两个不同的服务器(1211，1222)上。 此外，与每个对象副本有关的是用于表示每一个副本存在的时间长短 的生命期时间标记。正如在此将进一步详细描述的，当生命期期满时， 起动请求延长全局服务器上对象副本的存在时间。\n由于副本目录(666)对出错要求返回，所以对持久副本数据和与 它们的相关的本地服务器可被安全检查而无实质的数据丢失的风险。 然而，只是临时副本数据是不稳定的。为了恢复丢失的临时副本数据， 控制装置(520)需从全局服务器上查询一系列当前还未到期的临时 对象副本信息。应该指出，前面所述的服务器目录(656)(图6(b)) 可使控制器能够找出所有全局服务器的身份。通过查询控制器所辖范 围的每个全局服务器，控制器可能会根据需要重新提供对象目录。应 该指出，每个全局服务器的目录表可被检查以防止数据丢失。一本领 域内普通技术人员将意识：对副本目录(666)重新建后，未说明的 副本将会明显越来越不被使用，因为，无更多的请求通过该中间控制 器放到具体的全局服务器上。\n此外，在此将更进一步详细描述图11(c)，副本目录保存有关每 一对象标识符请求的统计信息，包括：预计需求量(”d”)、说明与请 求有关的控制地理区域的控制区域指示器(“g”)和需求量统计或需求 级(”r”)。此外，生命期时间标记，与每一副本相关。一旦时间标记 满期，当前拥有临时副本的全局服务器将向它的控制器(即：存放有 该副本的控制器)发出更新请求。此时，控制器可以拒绝更新而结束 副本或者通过延长其生命期(此时需要用新的副本重建数据库)接受 更新。如果控制器拒绝更新，则临时副本因被它的全局服务器删除而 结束。\n图6(b)描述了一个服务器目录服务机构(655)保存的服务器 目录例子，包括与其相关的服务器目录的图表和数据。在整个分布式 计算机环境(160)中，每台不同的服务器被赋予一个服务器标识符 (如：1211)。该服务器标识符假设是固定不变的。可能作为服务器 标识符的例子是服务器的IP地址或主机名(如：Name1(1211)和 Name2(1221))。就每一个服务器标识来说，一个被称为服务器能力级 的特殊字段用来标志该服务器的整个能力等级。也就是说，控制器利 用能力级来区分具有不同资源的服务器。本优选实施例，采用了两级 能力等级，即：HIGH(如：大型计算机/主计算机)和LOW(如：NT 级服务器)。当然，本领域内普通技术人员将意识可采用其它不同的 划分能力等级的方法。能力级是服务器的一固定参数，并且在初始化 时被设置。如一台服务器的默认能力级可能是LOW级。因此在本发 明中，不必要求控制器跟踪一台真正可用的服务器的能力级，就可使 控制器区别HIGH和LOW能力级的服务器。拥有临时副本对象的全 局服务器接收的是典型的HIGH能力级的服务器。\n另外，对于每一服务器标识符，有一用于保存该服务器的最近报 告的利用/意愿状态的特殊字段(如：服务器(1211)是RED状态， 而服务器(1221)是GREEN状态)。同时，对于每一服务器，由控 制器接受的其最近的利用/意愿状态报告的时间也被保存。如在图6 (b)中，服务器(1211)具有的时间标识是t1，而服务器(1221) 具有的时间标识是t2。最后，还有一个用于表示该服务器是全局服务 器还是本地服务器的字段。如服务器(1211)是本地服务器，而服务 器(1221)是全局服务器。应该指出的是，一台服务器可能既是全局 服务器又是本地服务器，在这种情况下，要利用两条不同的条目，一 条用于描述虚拟的本地服务器，另一条用于描述虚拟的全局服务器。\n返回来参照图5，控制器(520)还包括有会话模块(630)用于 选择一个或几个试探放置(620)，并执行一个查询策略去查询与那些 试探放置有关的服务器。最后的查询策略是根据搜索策略(635)和 会话策略(636)来确定的。会话策略是实现要精细的多次试探放置， 并基于某些准则，如价格来选择。一个策略库(640)用于保存和装 入各种策略(如：615，635，636)，并如这里所说的，定制控制器的 算法。应该理解，所有这些策略可在初始化过程中或根据需要装入的。\n图5中还说明了，控制器(520)还提供了用于监控服务器的全 局资源监控模块(650)。服务器目录服务机构(655)提供资源监控 数据。副本管理模块660应用探索去管理一个副本的生命期，特别是 判断是否一个副本应该创建、删除或移动。副本数据由副本目录服务 机构提供。控制信令模块(670)通过三种信令协议，即资源管理协 议(671)、副本管理协议(672)和放置管理协议(673)与各服务器 之间建立连接。按照本发明，放置模块(610)与放置管理接口(673) 协同运行，根据某一放置(615)或搜索策略(635)，形成和发送放 置询问(620)，对一个或多个这种愿意和能力放置。放置查询，顺利 的传送服务器上的接纳控制，被称为侯选接纳。侯选接纳不是传统概 念上的许诺接纳，在那里，资源只由服务器试探地保存一段相对较短 的时间(如：几秒种)，之后，由于服务结束，侯选接纳就没有保证。 正如在此要进一步解释的那样，会话模块(630)、会话策略模块(636) 和放置管理接口模块(673)协同运行：从一组肯定认可的侯选接纳 中，选择和保证一侯选接纳转为一个许诺接纳；除以前从服务器选择 的外，使服务器的所有其它的侯选接纳变成无效；及所有其它的待定 的放置查询无效。作为控制器(520)的一部分还提供了一个需求分 析模块(680)，用于检查请求信息流(605)，并形成下文称之为“热 对象(Hot Objects”)的最大请求对象表(681)、这些对象需求最大 的地区(682)和对它们需要的预测(683)表。这些统计信息被送到 对象副本管理模块(660)。一能力分析模块(690)为每一个最大请 求对象检查可用能力，并把其可用能力传递给副本管理模块(660)。\n如图5所述，本发明的系统依靠三个接口模块，即资源管 理(671)接口、副本管理接口(672)和放置管理接口(673)来转 换控制器(520)和服务器间的控制信息。本领域内普通技术人员将 意识到，存在着几种协议标准可易于实现这些接口。如资源管理协议 可基于RSVP和RTSP提供的功能来实现。一方面，预订协议 (Reservation Protocol)(RSVP)是一种集成服务因特网设计的资源 预订设置协议，一个应用程序调用RSVP协议为一数据信息流请求一 个特定的端对端的QoS，RSVP协议的目标是有效地设置可靠的QoS 资源预订，以支持单点传送和多点传送路由协议，及大的多点传送的 传递组范围。按希望，该RSVP协议将被用来提供基于每一节点的从 一多媒体服务器到其客户机的端对端的资源预订功能。另一方面， RTCP是与RTP一起工作的量测和控制协议。RTCP协议包被定期把 RTP对话中的每个参与者传送给所有其它的参与者。按本发明的要 求，应用层信息反馈被用来控制性能和诊断的目的。该RTCP协议将 用来在多媒体服务器和其控制器间反馈量测信息(如：资源管理协议 的MON_STATUS和MON_REQUEST消息)。而RSVP提供了在各 分布用户间实现服务会话质量的机制，RTCP提供了在各分布用户者 间传递量测和完成反馈信息的机制。类似地，副本管理协议是对因特 网文件传输协议(FTP)和RSVP协议的抽象化而形成的。而FTP允 许在各服务器间的一管道中以最大可能的效力移动内容，RSVP允许 对集成服务网络管道说明。\n正如所提及的，本发明的系统提供了在分布式计算机环境下集成 负载分配和资源管理的功能。最好是，控制器具有好几种自由度来使 需求和可能的能力匹配。首先，它控制和形成分布式的，及把需求放 置到服务器上。其次，按照某些准则，它控制和形成分布式的，并把 副本放置到服务器上(如：容量)。最后，控制器能视需要按照本发 明的机理在各服务器上动态创建、注销和移动副本，以达到其目标。 这些功能在此将被详细解释。\n                请求管理系统\n如图4和图5所述，本发明中，通过给出唯一对象标识符 的放置请求(如：501，601)，经过中间控制装置(520)，放置到具 有请求对象副本的服务器上(如：1211)。按照本发明的优选实施例， 控制装置根据当时的能力情况，执行几种机制，动态地重新形成需求： (1)第一步，根据控制器和请求参数的需要，请求可被升级或降级。 特别地，控制器基于在原始请求中找到的细微差别的参数值的请求， 可探测放置选项。(2)第一步，根据控制器的需要和各个请求的特定 要求，对暂时接近的相似请求可被推迟或组合。特别地，在任一时间 间隔内，例如，控制器会暂存、重新组织和成批处理一组相同的请求， 到具有多点转送能力的全局(多媒体)服务器上。(3)第三步，另外 一种处理，共享相似地理特征的请求，可根据控制器的需要和某一地 理范围内更有价格效益的资源利用情况进行组合。特别地，控制器可 以将客户机、服务器与地理约束联系起来，如：时区(如：EST)或 可用带宽(如：T1-line)，然后根据这些准则偏移请求放置。\n为此，控制器起到了象一个统计信息集合点的作用。特别地，有 两种统计信息，即需求统计和能力统计由控制器保存。一方面，控制 器(520)用需求统计来描述过去的请求特征。在优选实施例中，根 据那个特定的控制器的观察，通过控制器分析的不同客户机的集合请 求流信息，得出预期需求统计信息。如：这些统计信息用于形成需求 密度、需求量和与该需求有关的地区特征。另一方面，控制器利用能 力统计信息来说明为多媒体对象接收位置的有关多媒体服务器的能力 特征。在优选实施例中，可用能力由服务器粗略估测出，并由服务器 根据需要发送到控制器(520)。\n按照本发明的优选实施例，系统将接纳控制权分散到各服务器本 地来实现。图10是对图4中的全局服务器1211的一个更详细的描述。 如图10所示，每一服务器(如：服务器1211)提供了一个接纳控制 机构(1040，1041)，它可以使该服务器允许或拒绝一个侯选接纳放 置查询请求，并把这应答反馈给控制器。该接纳控制机制(1040，1041) 可以使侯选接纳转为许诺接纳，及可使一个侯选接纳失效。控制装置 (520)并不完成任何接纳允许连接控制和资源预订任务。本领域内 普通技术人员将意识到本发明适合于服务器集合和服务器簇的情况。 特别地，由于一个集中的接纳控制与每一服务器簇相联系，所以该服 务器簇将作为HIGH能力的单个服务器出现在控制器上。因此，服务 器和服务器簇之间没有任何特别的差别。\n控制器、客户机和服务器之间的信令协议，在此称为放置管理协 议，被用在这些分布式用户之间，它可允许控制器(520)将一客户 机的请求放置到某一服务器上，对此，图7有更详细的描述。该协议 包含至少以下各种消息的实现过程：客户机所使用的CID_REQUEST 消息，用于将请求提交到控制器、控制器使用的CID_QUERY消息， 用于在服务器中探测侯选位置，以及控制器使用的CID_PLACE消 息，用于请求促使候选接纳成为许诺接纳。此外，以上每种消息都与 认可消息CX_ACK有关连，CX_ACK消息用信令组响应上面的异步 消息CID_REQUEST、CID_QUERY和CID_PLACE中的任意一个。 因此，对于CID_QUERY消息，CQ_ACK消息返回一个表示候选接 纳已被允许的肯定认可。该消息指示了接纳截止期。本领域内普通技 术人员将意识到该期满日期可由每一服务器根据服务器的活力的不同 而配置，以寻求的新放置方式。此外，在某些实施例中，根据服务器 的可用能力可使超时延迟可变。对于CID_PLACE消息，CP_ACK 反馈一个指示是否候选接纳已成为许诺接纳的标识。\n总的来说，将一个请求映射到某一服务器的过程，被控制器分解 为三个阶段。第一，控制器去识别一个或多个服务器，从包含请求对 象副本的那些服务器中，了解意愿，考虑接纳查询。第二，按照 CID_REQUEST消息，依靠可能提供给控制器的某些可选参数，控制 器用接纳查询去查询这些服务器中的一个或多个。在本发明中，可能 随着客户机的介入，该过程也许要重复多次，直到在服务器和控制器 间达成协议为止。第三，控制器将请求放置到在最后一步能找到的其 中一台服务器上。由于在进入第三阶段之前，前两个阶段可能要重复 多次，所以，在本发明中，将一请求映射到一服务器上的过程是一个 反复的过程，其中包括了动态的对一系列可行的侯选接纳进行探测和 会话。\n在此需要指出的是，控制器的副本目录服务机构(665)提供了 跟踪每一副本位置的机制。设给定一个唯一的对象标识符，查找副本 目录(666)在系统中获得相关副本的位置。在优选实施例中，副本 的位置是用其所在的服务器的地址(如：主机名或IP地址)表示。 应该注意，每个服务器上只有一个副本就足够了。\n图7是放置管理协议的一个活动时间图。如图7中所示，在时间 t，控制器(520)接收到来自客户机(如：110)的CID_REQUEST 消息(710)。在时间t1，控制器(520)分别向两台已知愿意和考虑 接纳查询的服务器(1201，1211)，发出CID_QUERY消息(739，740)。 每一CID_QUERY消息，包含了待请求对象的唯一标识符(741)， 还有其它的参数(742)如：分辨率、质量、价格和/或以名称数值对 形式表示的最大延迟时间。这些参数(742)可能与由客户机发出的 CID_REQUEST消息(710)中所指定的参数(731)一致，或者是对 这些参数的精选。这些参数(742)可按照与该特定的请求相关的会 话策略(636)独立地与每一服务器(1201，1211)会话。\n在时间t2时，服务器(750))通过CQ_ACK消息(760)响应 控制器(520)。该消息中包含了标识信息(770)，用于表示是否一侯 选接纳已被服务器(1201)许诺接纳。该消息中还包含了该侯选接纳 的截止期(772)及会话的名称数值对，如果这样，对CID_QUERY 消息参数(773)相关的参数信息，该特定服务器(如：1201)愿意 提供侯选接纳。\n同样地，图中显示了在t3时间时，第二台服务器(1211)通过另 一CQ_QCK消息(761)向控制器(520)发出反馈信息。当CQ_ACK 消息指示侯选接纳由服务器接收时，则CQ_ACK消息(如：773)中 的参数字段中会描述出特定的参数值，相关的服务器愿意提供服务。 控制器在合理的时间内(如：几秒种内)等待一个或多个CQ_ACK (760，761)。然后，根据会话策略(636)，控制器(520)可能从当 前接收到的CQ_ACK(760，761)中选择其中之一(如：760)。\n当然，也可能无侯选接纳被确定。这可能由于以下几个原因：(a) 所有的服务器中缺乏资源；(b)各会话参数缺乏统一性；(c)会话的 最后期限已满；或(d)上述各原因的组合。最好，会话期限能保证所有 请求的公平性。这种方法可使控制器不会在牺牲其它请求时间的情况 下过多地将时间花费在为不可行的请求，进行徒劳的查找上。显然， 会话期限应为系统参数。\n特别地，由于服务器和对象之间的距离，这期限应在几十秒的数 量级上。在任何情况下，控制器都要涉及与特定的请求相关的会话 (636)，以决定在该条件下应有的合理处理。几种可能的处理可以被 应用，如请求一系列新的参数(731)，或对寻找的侯选接纳重新评价 探测策略(635)，然后以新的设置重新给各服务器发送CID_QUERY 消息。\n活动时间图上显示了在t4时间时，控制器(520)向所选择的服 务器(1201)发送CID_PLACE消息。该消息包含唯一标识符(730)， 及使该服务器从侯选接纳升级为许诺接纳。该服务器通过CP_ACK 消息(791)认可该升级。\n回到图5，每个放置建议(620)是和一映射策略(也称为放置策 略)(615)联系在一起的。例如：以前的这种放置/映射策略(615) 能指定，“总是将请求放到具有LARGE能力的服务器上的GREEN 副本上”。一旦控制器选择了与某放置信息有关的侯选接纳，则该位 置将被控制器所许诺。然后，控制器就对该位置获得了许诺接纳并可 管理该位置。该许诺的期限由控制器的放置策略来指定(如：“总是 把请求放置到HIGH能力服务器上的GREEN副本上，并且要使该放 置能容忍服务器失效)。因此，在它的生命期内，控制器将监控这种 绑定性能。另外，在该绑定的整个生命期内，可能会发生妨碍其绑定 性能。如典型用户的非线性交互作用(如：录像机的停止、倒带、暂 停、继续)可能会妨碍线性播放模式下假设的，由典型的视频点播服 务器来强制建立的绑定。同样地，服务器失效典型地会中止绑定。根 据控制器选择的放置策略，控制器会确保这绑定性能，不管是否有这 种情况的发生。例如有了这种容错保证的绑定，即使该服务器中断绑 定，控制器也会试图自主地寻找一个新的位置，以重新改进。\n还是如图5所示，本发明的一个方面是，控制器会在同一时间内 同时探测多个放置建议(620)，而不是各自独立地探测每一可能的放 置建议。这种行为是通过一探测策略(635)为控制器指定的。例如 一个这样的探测策略可能被指定为“最多重复K次，在每次重复时探 测至少I个但不多于m个服务器”。对于那些不成功的请求，探测策 略可扩展。如在该种探测策略下，为每一不成功的请求，启动总共至 少有N＝k·I个会话方案，每一会话方案至少产生两条(2)消息。， 本发明允许每一请求与一测策略方案相联系。显然，这种同时对服务 器和副本的探测可能会导致同一种请求被映射到不同的服务器上。还 应指出，所给的特定的请求，控制器会产生0个或多个放置建议。如， 当可用能力不能充分满足一请求时，将不能产生放置建议。\n回到图7，还应知道，挂起的CID_QUERY消息可能会被控制器 抛弃。例如，在本发明中，控制器会直接抛弃对其不再感兴趣的放置 查询(例如，如果对请求的响应超过了最长等待时间阀值)。该会话 配置由会话策略(636)指定给控制器(图5)。例如，某一会话策略 可能被指定为：用服务器会话一组参数x，这样，这些参数y同原 始参数x(731)之间的价格差最多为Z。\n                    集合驱动的响应\n如上所述，本发明的系统试图将服务器的能力与预期需求相匹配。 为此，本发明使控制器(520)通过在分布式计算机系统中监控需求 和能力来实现资源管理。特别地，控制器试图为副本，按照服务器的 可用能力以及服务器上副本的放置，匹配预期的集合需求。预期需求 的统计值是通过分析来自不同客户机的请求信息流而产生的。可用能 力通过监控和查询服务器而估算出来的。\n控制器(520)保存了关于对象、副本、服务器、请求以及它们 位置的永久的和动态的状态和数据。例如，在优选实施例中，目录服 务用于保存特定的对象的需求、副本的位置、服务器的能力和请求的 时间分布数据。应该理解，在该优选实施例中，这些数据结构能使数 据丢失以及数据讹诈恢复原状。\n选择那个对象能有效的复制候选(在此称为“热对象”)，是按照 准则形成的，如对对象标识符的预期需求。在优选实施例中，复制候 选对象的选择是通过对可用能力预期需求集合的在线分析来决定的。 也就是说，根据第一实施例，副本管理试图使预期需求与可用能力相 匹配。另一方面，副本管理试图将预期需求和与客户机地理位置相近 的某对象标识符的可用能力相匹配。\n在这一点上，本发明的系统把各请求组合成几组具有相同特性的 请求组。例如：按照某些准则，控制服务器把在某一时间间隔内从各 独立的客户机接收到的请求，根据放置目的按组进行管理。相关请求 准则的例子包括有(但不仅限于此)：(1)请求同一对象标识符的客 户机的地理相近性；(2)对请求限制的公共性，如：分辨率和质量； 及(3)相同对象标识符在请求到达时间的时间相近性。\n根据本发明，任何特定的请求可能被它的控制器自动地提升或降 级，以便将同一对象标识的、有细微差别的各请求转为相似的请求。 例如，这可以通过降低组合准则地理相近性的灵敏度、降低请求对象 的质量、降低组合准则时间相近性的灵敏度、或者以上几种的组合等 来实现。控制器是否运用这种选项取决于客户机、请求、和/或对象特 性如价格性能。但是，还应注意，控制器可决定用与其它请求无关的 方式，管理有关同一对象标识符的请求。\n如上所说，控制器装置监控请求超时的分布情况，在优选实施例 中，可以得到对每一特定的对象标识符的请求的分布情况的统计值。 需求统计值提供了关于对同一对象标识符的相对的需求信息，而且可 按需求对各对象标识符排列。尤其是，每一对象的统计特性包括：(1) 需求密度；(2)需求量；除此之外，每一对象的统计特性还包括(3) 与需求相关的地区。控制器对分布式对象集合中的每一对象保存需求 统计。对特定对象的需求统计值，根据这种对象的每个请求被更新。 特别地，控制器对处于高需求状态的对象(如：热对象)进行标记。图5 中的需求分析模块(680)实现需求统计值的计算，对一特定对象， 用图11(a)到图11(c)描述。本领域内普通技术人员将意识到，为 提高该值的可信度和准确性，存在很多计算需求统计值的方法，。\n图11(a)描述了，在连续的时间间隔tn-3，tn-2，tn-1，t内，控制 器所监控到的一个或多个请求信息流(1110a，……，1110d)。每一请求 与对象标识符(对象01)和地区指示器G1，G2，G3和G4相联系，该 指示器用于唯一识别与请求的客户机相联系的地区。例如，图8描述 了一个动态控制将副本01，02和03放置到各个全局服务器830，840， 860上的分布式计算机系统，那里的需求和地理趋向用于区别永久的 和临时的副本。临时副本总是驻留在一个或多个全局服务器上，并且 具有一个由控制器所决定的动态生命期。控制器按照某些准则如价 格、需求和能力，管理将副本动态放置到全局服务器上，这些以后将 详细解释。最好，相关的地区G1，G2，G3或G4既定的由系统管理 员表明，与已知的地理区域，如美国的东部标准区域或太平洋标准 区域或东北部和西南部匹配。然而，地区可由控制器动态设置。例如， 控制器可能按照属性或特性将客户机分组，并利用这一准则帮助类似 的请求进行放置。\n回到图11(a)，图中描述了在请求信息流中，对被请求对象标识 符(01)生成请求密度统计值。图11(a)中所示的例子描述了在4 个时间间隔(如：T(n-2)(1110a)和T(n)(1110d))中的需求统计值 的计算。密度需求统计值由每一限定的时间间隔T(j)内的请求的数量 来计算。本例中显示了需求统计值的变化，从第一时间间隔(T(n-3))的 10/T到第二时间间隔(T(n-2))的13/T，到第三时间间隔的15/T，到 所示的最后时间间隔的16/T的变化。应该注意，需求统计值在控制 器使用之前可能被平滑，以增加其鲁棒性。\n另外，图11(b)还描述了与图11(a)有关的支配地区的统计值 的计算。在本例中，整个系统被分成4个既定地区(G1，G2，G3， G4)。控制器分析之前，用控制器按他们进入地区触发请求。在每一 时间间隔T(j)内，对指定对象的每个输入请求，控制器按地区对它们 进行排序，并更新与每一地区有关的请求数量(未显示)。这样，对 每一时间间隔内的请求信息流，实现需求趋向的监控。在图11(b) 中，如地区G4，根据前面时间间隔内对象01的请求数量的稳步增长， 指示出在时间间隔t(p)，对象01的需求的预期增长的趋向。也就是说， 在图中所示的4个时间间隔内，地区G4总是成为支配其他地区G1， G2和G3的区域。还应该注意，支配地区指示在被控制器使用之前可 能被平滑，以增加其鲁棒性。\n图11(c)更进一步描述了用于保存每个副本的需求统计信息图 表和数据的结构(696)。对于每一对象标识符，控制器保存有关预期 需求的统计值。根据当前预测及平滑的事例，移动窗口统计被使用。 一个时间间隔(在此称为T)用来平滑需求统计值。K*T大小的活 动窗口用于预测需求统计值。所用的平滑技术的类型(如：指数平滑 或均匀平滑)及其预期的鲁棒性或可信度决定了平滑的时间间隔的数 量(K)。用于更新需求统计所用的时间间隔的大小应该足够大，这里 需要：(a)减少开销，(b)平滑瞬间影响，(c)跨越足够大量的请求。 另一方面，较小的T和K值，使控制器更迅速地反应变更。当前实际 应用的因特网范围的合理的取值是用K＝2及T＝[60，……，3600]秒 的指数平滑法。这样，在图11(c)所示的数据结构例子中，请求密 度统计值(1150)描述了与该相应的对象标识符相关的请求密度，这 些对象标识符是在最后K个时间间隔(T)内(如：j，j-1，……，j-k+1) 由特定的控制器观察到的。支配区域指示器(1160)描述了与对象标 识相关的支配地区。需求量统计值(1170)提供了最后K时间间隔T 内的请求数量的总和。控制器查看需求密度和需求量统计值，来评价 某一对象的需求是否高。这样，控制器查找所有具有高需求级、高需 求密度、特别是两者都高的对象。控制器通过“热对象”布尔型字段 (1180)来标识所知的处于高需求状态的对象。该字段的值为“YES” 表示该对象标识处于高需求状态。最后，时间标记(1190)用来跟踪 最后需求评定的时间。本领域内普通技术人员将意识，最好应避免使 用太陈旧的评价方法，因为这种评价的可信度低。最好，控制器并不 局限于仅仅依靠对象标识来跟踪支配地区。例如，可以根据每一副本 来跟踪支配地区统计信息。这种跟踪可使控制器高效地觉察某一特定 的副本(与某一特定的地区相联系)是否结束(从长远的观点看)来 自不同的支配地区的服务请求。因此，副本迁移机制提供把位于某些 支配地区的服务器上的副本迁移一新的与过去位置相关地区匹配的全 局服务器上的能力，使副本可适合这种情况。对象迁移机制是作为在 此将要详述的能力形成机制的一部分来实现的。此外，支配地区的最 近的历史情况可用于估计与给定的副本或对象标识符相关的支配地区 中变化的稳定性。\n用于监控和评估可用系统能力的方法，是通过资源监控子系统的 使用来达到的。资源监控系统，通过资源管理协议与服务器相接，该 协议可使某一服务器通过MON_STATUS消息报告其可用的系统能 力。特别地，MON_STATUS消息还向控制器传递该服务器将来可用 状态的预测。该预测情况无约束力，也不被控制器当作合约，相反地， 该预测情况被认为是用来指示该服务器处理图7中所述的 CID_QUERY消息的意愿。在本实施例中，服务器处理新请求的意愿 是如下所述随它的可用能力而变。由于这个原因，控制器将其看作是 某一服务器的应用/意愿性状态。\n按照本发明的优选实施例，关于图6(b)所述的应用/意愿性状态指 示的目的是双重的。第一，从控制器的观点来看，应用/意愿性指示根 据服务器资源利用量度的大小表示地址不均匀性。特别地，本优选实 施例使用了三色水印作为其应用/意愿性状态指示，该指示与服务器 无关。这一方案，连同服务器能力等级，可允许控制器比较不同服务 器的相对利用情况，以处理未来放置请求。结果，系统中任何服务器 的应用/意愿性以6(3×2＝6)种情况来量度，这6种情况由三种利用 状态(GREEN，YELLOW，RED)和两种能力级(HIGH，LOW)。\n另一方面，应该注意，每一服务器可能会独立地设置其应用/意愿 性指示值，以适应其需要。特别地，服务器能设置其RED，GREEN 和YELLOW水印域值以适合与反映特定的利用等级值不同的它们各 自的意愿。此外，可预想到，这种意愿值可能会动态地变化。然后， 这种变化将表示响应服务器将来需求的变化。这一问题的第二个方面 在此被称为某一服务器获取放置查询的挑衅性(aggressiveness)或意 愿性(willingness)。也就是说，从服务器的观点来看，应用/意愿性状 态指示方案可能会被服务器管理员使用，以定制挑衅性，或从控制器 寻求放置时缺乏服务器。换句话说，两台具有相同资源和相同物理位 置的服务器可能会接收非常不同的放置查询，这取决于它们各自赋予 的利用状态是如何的。特别地，服务器的管理员可设置三种利用状态 (GREEN，YELLOW，RED)的阀值，为适合服务器管理的服务需 要。例如，某些服务器可能会对理解高度可靠性和具有强大的服务保 障感兴趣。在这种情况下，服务器的管理员会将GREEN区的值定制 成保留值(例如：这些真正能力的50％的低值，却花费100％高工程 能力，以保障服务)。另一方面，其它的服务器可用提供服务商业质 量为低价格服务，这种服务如偶而的不稳定信号或拒绝服务。在这种 情况下，服务器的管理员会将GREEN区的值定制成挑衅性的值(如： 象真正能力的85％这种高值，这样，就将YELLOW区和RED区压 到了只有15％松驰度)。结果，由于YELLOW和RED区表示用于容 纳复制请求和资源利用随机性的资源松驰度，所以减少了这一资源松 驰度会侵害到在GREEN区的已接收的信息流连接的服务安全保障。 但是，这种服务器会观察到来自控制器的大量的放置请求。可以想像， 这种服务器然后会根据某些渴望的准则，如从税收或统计查询中拾取 和选择。\n图9(a)和图9(b)通过一个例子，描述了优选实施例所规定 的具体的水印方案(900)。该水印方案(900)由服务器将其利用状 态映射成正常的意愿指示(990)而被使用，控制器可以依赖跨接所 有服务器。\n特别地，图9(a)描述了在有应用负载时，一特定的服务器(如： 服务器1)利用/意愿性的分布(960)。服务器发RED状态(910) 给控制器，表示当前服务器将不再接收更多的ID_QUERY消息。服 务器发YELLOW状态(920)给控制器，表示当前服务器将不再接 收更多的ID_QUERY消息，但可接收挂起的PLACE消息。最后， 服务器发GREEN状态(930)给控制器，表示当前服务器可接收 ID_QUERY消息。这一标记由每个服务器周期性地更新，以指示其 当前的应用/意愿性状态。只有当服务器经历了改变其意愿性指示时， 服务器才向控制器发送MON_STATUS消息。尽管用三个标记要考虑 6种情况，但两种情况是重要的：(1)从GREEN状态向 YELLOW/RED状态变化，如图中点(940)所示；和(2)从 RED/YELLOW状态向GREEN状态变化(950)。\n图9(b)也描述了当经受与服务器1相同利用的情况下，从另一 服务器(服务器2)所得到的不同利用/意愿性状态的分布(961)。应 该注意，每一服务器会独立地将RED、GREEN和YELLOW标记设 置成适合它们各自的意愿，以接收CID_QUERY消息。除了利用/意 愿性状态外，能力级被用于指示是否该服务器是HIGH能力还是LOW 能力的服务器。服务器能力级的决定是基于该服务器在GREEN状态 能同时提供的信息流的最大数量的简单的阀值检查。至此，GREEN副 本被认为是在处于GREEN服务器上的副本。同样地，GREEN服务 器是指一台其最后的利用/意愿性状态(990)是GREEN状态的服务 器。\n回到图5，资源监控/管理协议(671)允许服务器向控制器报告 其利用/意愿性状态，如：GREEN状态，和其能力级，如：LOW。 服务器使用MON_STATUS消息向控制器报告其利用/意愿性状态和 能力级，该消息标识了发出报告的服务器(如：利用其IP地址或主 机名)、控制器、服务器报告时的时间、利用/意愿性的新状态和能力 级(下文将详细描述)。\n先进先出(FIFO)顺序传输机制，如：TCP，用于各服务器和控 制器之间，以保证按顺序接收消息。每一新的MON_STATUS消息复 盖了控制器上的相关服务器上次报告的状态。然而，如果该服务器的 能力级报告为空时，则控制器为该服务器记录的能力级不变。此外， 如果MON_STATUS消息丢失时，系统则以下列方式进行恢复：如果 丢失的消息指示了向RED状态的变化(940)(图9(a))，那么任何 以后的放置请求(即：CID_QUERY消息)将不能通过该服务器上的 接纳控制。这些事件被服务器看作是违反了控制器和各服务器间的放 置请求协议的。结果，如果需要，该RED服务器将向有疑问的控制 器重发RED MON_STATUS消息，以避免接收任何更多的 CID_QUERY放置消息。\n如果需要，控制器可从某一特定的服务器请求资源监控状态。通 过MON_REQUEST消息，资源监控协议也可以使控制器能询问利用 /意愿性状态。此外，当对某一特定对象标识的请求来评价时，能确定 任一服务器上的真正可用的GREEN状态的能力。当判断是否将一对 象的新副本放置到全局服务器上时，论询特定的服务器的能力对控制 器来说是有用的，这通过副本放置处理(1400)如下文详述的完成。\n上面有关图11(c)中所述的需求统计值和数据结构(696)可进 一步被控制器用于跟踪各服务器报告的能力和利用/意愿性状态。如图 11(c)所示，需求统计值和数据结构保存了有关某一对象标识符的请 求的统计信息，包括：预期需求“d”、需求量统计值或速率，即每个 时间间隔对该对象副本的请求活动性，和指示被请求的对象是否为代 表其活动的概况的“热对象”。与对象标识ID有关系的可选项是代表 与对象请求有关的支配地区的区域指示“g”。此外，一生命期时间标 记与每一副本相关。一旦时间标记到期，则当前拥有该临时副本的全 局服务器向控制器(即控制器放置该副本)发出延长时间的请求。这 里，控制器或者拒绝更新而结束该副本，或者延长其生长期(因此， 用该新副本重组数据库)。如果控制器拒绝延期，则该临时副本由其 所在的全局服务器删除而结束。本领域内普通技术人员将赏识定期检 查这些数据结构对容错是可取的。应该注意，如果发生某一数据丢失 的情况，则通过让控制器利用MON_REQUEST消息查询各独立的服 务器来重新组建该数据。对于报告是不可用状态的服务器来说，其相 应的利用/意愿性状态默认为是RED状态，并且其能力级空着，直到 从该服务器收到MON_STATUS消息。这种方法增加了控制器对正处 在利用状态的服务器失效情况的容错能力，因为在该服务器的利用/意 愿性状态重新变为GREEN状态之前，任何新的放置请求将不会赋予 给该服务器。\n能力的地区形成\n正如前面所提及的，控制器(520)在匹配能力需求时，具有几 个自由度。第一，它控制和形成服务器上请求的分布和放置。第二， 它按某些准则，控制和形成服务器上副本的分布和放置。第三，为达 到其目标，控制器能根据需求的需要，利用本发明的机制在各服务器 上动态地创建、销毁和移动副本。\n关于动态地创建、销毁和在各服务器上移动副本的能力，对象副 本允许随着预测的有关需求和可用能力的预报，在服务器上迁移。所 以，本发明提供了不但能调整请求放置，而且更重要的是，调整整个 网络中副本放置的机理。该副本管理技术取决于预测的请求需求和可 用能力的特征。\n图8通过一个例子描述了对一个分布式计算机系统的需要，该系 统能根据某些准则，如在优选实施例中所指示的需求和地区，动态地 控制将副本放置到各全局服务器上。在本例中，有4个地区(G1，G2， G3和G4)大体上分别与东北(G1)、东南(G4)、西北(G2)和西 南(G3)相对应。本地服务器(830)位于G1分区，全局服务器(840) 位于G4分区。系统中还包括了另两个全局服务器(850，860)。全局 服务器(850)覆盖了G2地区，而全局服务器(860)覆盖了G3地 区。该系统中包含了一分布式对象集合。在这种情况下，该集合由三 个不同的对象(01，02，03)所组成。这些对象中的每一个都与可能 在整个系统中，即全局和本地两类服务器上找到的副本相关。在本发 明中，在本地服务器上所找到的副本称为持久副本，而在全局服务器 上所找到的副本称为临时副本。对于在该分布式集合中的每一对象， 可能在整个系统中有零个或多个临时副本。\n在图8所述的例子中，有三个持久副本：对象01(820)、对象02 (800)和对象03(810)。所有这些副本都可以在G1本地服务器(820) 上找到。另一方面，对象01具有一个临时副本(801)，建立在G4全 局服务器(840)上。而对象02具有两个临时副本(811，812)，分 别建立在全局服务器G4(840)和G3(860)上。对象03表示的对 象由G1本地服务器经它的持久副本为它提供了足够的能力。因此， 在系统中，对象03无临时副本(当前)被建立。而且，在本例中， 对象02代表了一个被预测为高需求的对象，即热对象。本例中假设 了通过历史分析表明，对象02的相当数量的请求，是从地域分区G3 发出的，这表示对象02有一关连的“支配地区”。根据有关对象02 的支配地区和需求统计，系统确定将一个副本放置到G3分区是所希 望的。因此，对象02的一临时副本被暂时放置到全局服务器G3(860) 上。\n临时副本具有一个由控制器决定的动态的生命期。临时副本的生 命期，例如，取决于需求与同相应对象有关的可用能力的比较，以及 该对象期望的对话期限。例如，对于典型的90分钟的电影，有挑衅 性的2小时的截止期，其中30分钟分配给用户交互和用于控制器对 截止期更新的拖延时间。很明显，能够使用较小挑衅性的截止期(如： 对于90分钟的电影，采用24小时的截止期)。当期望一对象在这种 时间有需求，但是，在这一时间期限，其需求可能不足以大到保证其 成为热对象时，可使用这种方案。此外，每次新请求被放置到临时副 本上，副本的上述生命期限，可重新设置。\n如图8所示，临时副本驻留在全局服务器(840，850，860)上， 这些服务器为与对象集(如：800，810，820)相关的一系列动态的 副本集(如：801，811，812)，提供存储和数据流资源。在本例中， 对象01(800)的临时副本(801，811)建立在全局服务器(840)上， 而对象02(810)的临时副本(812)建立在全局服务器(860)上， 而对象03(820)没有临时副本存在。此外，在图8所示的例子中， 所显示的第三台全局服务器(850)是可用的，但其上无任何临时副 本。控制器能按照某些准则，如价格、需求和能力，管理副本在全局 服务器上的动态放置。\n图10更进一步详细描述了图8中所示的任何一服务器(如：服 务器(830)或(840))的模型。如前面所说，一台服务器为这些对 象提供存储和/或数据流资源。但是，服务器(1000)现在被分成两个 独立的部分：一本地部分(1010)和一全局部分(1020)。两部分为 它们的集合(1011)和(1021)中的对象提供独立的存储和/或信息流 资源。这些集合(1011，1021)被独立地管理。而且，本地部分(1010) 具有一封闭的成员集合(1011)，全局部分(1020)具有一开放的成 员集合(1021)。如前面所说，对于全局部分来说，成员由控制器来 管理，而对于本地部分来说，成员由服务器本地管理。应该知道，服 务器可能只用于一个部分(即：一部分为100％，而另一部分为0％)。\n按照优选实施例，一个分布式系统可能包括两种不同类型的服务 器：(100％)本地服务器的集合和(100％)全局服务器的集合。因 此，在此说明的关于图2的服务器实施例，在图10中的每一部分 (1010，1020)包含了5个软件模块或过程。\n服务逻辑模块(同图2所示)提供了在服务器上的面向应用的功 能。这一面向应用功能的例子是记账和管理客户机对任何信息流会话 的交互。信息流处理(275)提供了将多媒体内容从服务器传递到客 户机的网络信息流能力。这一功能通常是按照某些标准协议如：RTSP 来实现的。接纳控制处理(1040)实现典型的接纳控制任务，这些任 务用控制器发出查询。接纳控制处理(1040)评价一个请求并产生接 纳意图给控制器(在此称为由控制器侯选放置)。资源管理处理(1050) 提供了增强的资源监控功能，使控制器能够确定关于服务器的面向属 性的集结，如服务器的利用/意愿状态以及能力。资源管理协议(671) 规定用于监控和查询服务器状态的信令消息(如：MON_STATUS， MON_REQUEST)。最后，复制管理处理(1030)表示加到服务器上 的一个新处理，使其能够创建和删除全局服务器上的临时副本。在此 所述的复制管理协议提供了能使进行对象按需复制的信令要求。每一 信令接口(1031，1041，1051，1061)可使服务器遵循控制器上的相 应的放置管理、资源监控、信息流和副本管理处理。如所述的，全局 服务器上的对象集合是开放的。当与集合中的其它对象比较时，对象 可以基于例如特定对象的如预测的需求的因素，加入到集合中。同样 地，对象也可以基于例如特定对象的如相对利用或收入因素从集合中 离开。这个动态集合的管理可以由控制器，经副本管理信令协议自动 控制，副本管理信令协议被用于服务器对象上的复制，以经全局服务 器上的副本迁移。\n例如：对任一给定的对象可以实现最大临时副本数N。这个数可 以是先确定的，或在运行期间动态设置，并且每一不同的对象可能具 有不同的最大临时副本数。此外，与任何给定的对象相关的临时副本 数整个时间内将变化，如：当需求增加时、该对象是热对象时、或能 力低时，可能自动增加；或者当需求减少时、该对象不再是热对象时、 或相对于预测的需求能力太高时，可能会减少。\n尤其是，副本管理系统包含了4个过程和实现对象按需复制操作 的补充信令协议(如：副本管理协议)。副本管理系统负责对服务器 上(即：副本和/或请求的放置)控制器的调整响应，这种调整响应按 某些属性的约束如服务器的资源能力，直接指定到特定的服务器。特 别是，相同的全局服务器上的放置请求和副本请求可视观注，以满足 象分别由客户机和内容作者提出的明确的共同分配约束。\n在本发明中，请求(即，需求)和副本(即，能力)管理系统之 间的交互分别由称为初始不足(preliminary scarcity)和供给过剩检 查(oversupply check)的两个需求对能力(即：单方向的)触发器 组成。一方面，当对某一特定的对象的需求预测增加时，请求管理系 统用初始不足检查从副本管理系统请求一不足能力检查，另一方面， 当一特定的对象的需求预测减少时，请求管理系统用初始不足检查从 副本管理系统请求过量能力检查。如果初始检查发现了一种可能的需 求对能力(demand-to-capacity)的情况，从副本管理系统请求一综 合分析，这可能导致副本的创建和/或删除。为此，这些检查被称为初 始检查，由于它们的目的是在副本管理的额外开销和挑衅性间提供一 种平衡。\n根据本发明中所述的一些条件，能力形成机制将被激活。特别是， 请求管理系统的初始检查被用来识别一可能的不足情况(这里称为所 给的预测需求的可用能力不足)。该检查用于触发能力形成机制的激 活，并被称为副本管理系统。同样地，初始检查用于识别某一可能的 过剩情况(那里称为所给的预期需求的可用能力过剩)。该检查用于 触发能力形成机制的激活，副本管理系统和请求管理系统(即：需求和 能力调整)的上述集成参照图12，在此详述，图12描述了下面要叙 述的副本管理系统的各种处理之间的相互作用的高层次图。\n如图12所示，初始不足检查(1405)由请求管理系统首先实现 以识别可能的不足情况。在完成将服务绑定到请求管理系统后，初始 不足检查(1405)开始。正如在优选实施例中所用的初始不足检查 (1405)在图13(b)中进一步作详细描述。\n如图13(b)所示，在优选实施例中，初始不足检查(1405)确 定是否留下的请求对象的GREEN副本少于两个(1410)。本领域内 普通技术人员将意识，初始不足检查(1405)可用不同鲁棒性和挑衅 性的几种不同方式执行。例如，优先项可给予被选择的对象中先定者。 这种情况下，初始不足检查(1405)就被修改以反映这种偏移。当发 现某一可能的不足情况时，检查请求(1415)被提交给副本创建处理 (1300)。检查请求(1415)识别上述的对象(如：420)，其目标是 从副本创建处理(1300)对该特定对象请求更综合的评价。在优选实 施例中所使用的副本创建处理(1300)在图14中将进一步描述。特 别地，只有当这种检查请求(1415)被提交时，该副本创建处理(1300) 才运行，否则，无检查被触发(1499)。副本的创建导致副本目录(656) 的相应更新。\n进一步观测图12，副本创建处理(1300)的目的是要确定是否检 查请求(1415)中指定的对象(如：对象01)，真正需要一个新副本。 如果发现需要一个新副本，一个放置请求(1710)到副本放置处理 (1400)中排队。在优选实施例中所用的副本放置管理处理(1400) 在图15中详述。放置请求(1710)指示该特定的对象(如：01)符 合复制准则并应创建一个副本。在优选实施例中所用的复制准则 (1800)在图15中进一步详述。特别地，复制准则依靠基于控制器 的数据结构，如需求统计值(696)、副本目录(666)和服务器目录 (656)来完成需求到能力的评估。\n副本放置处理(1400)选择一个挂起的放置请求(如：1710)， 如有一可能，对这一请求确定一个新副本位置。本领域内普通技术人 员将意识到可能有几个挂起放置请求可被排队，并且当复制资源低 时，价格计量准则(放置策略)(1745)可用于把对象的复制区分优 先顺序。在本优选实施例中，使用先进先出(FIFO)顺序。\n如图12和15还显示的那样，副本放置处理(1400)的一个目标 是基于某些设定的准则(1440)去识别一个源服务器(见1720)和目 标服务器(1730)。在本优选实施例中，控制器以类似于在此所述的 请求放置方式探测和会话(1440)复制选项。这是通过图12所示的 和图18中更进一步详述的副本管理协议(1200)提供的调用查询功 能来完成的。\n一旦源服务器(1720)和目标服务器(1730)被识别时，即在(1450) 步接受选项，副本管理协议(1200)为相应的放置请求(1710)排队 复制请求(1740)。这是通过调用副本管理协议(1200)调用复制功 能来完成的。本领域内普通技术人员将意识到在复制期间会出现几种 情况。在本优选实施例中，复制策略(1765)允许在此所述的副本管 理处理下定制例外情况处理。\n类似地，副本管理系统提供了删除副本的能力。请求管理系统用 初始过剩检查(1505)识别可能的过剩情况。在图13(a)中进一步 详细描述了在本优选实施例中所用的初始过剩检查(1505)。初始过 剩检查(1505)在服务绑定期间发生。此外，它还应用于服务器请求 临时副本更新的时候。当某一可能的过剩情况被识别时，检查请求 (1515)的请求被提交到副本删除处理(1500)。副本删除处理(1500) 用于如图16中更进一步详细描述的在本优选实施例中。\n副本删除处理(1500)的目标是判断是否相关对象根据整个需求 对能力准则(1800)去删除特定的副本。在本优选实施例中，临时副 本被认为是基于其生命期限、需求对能力和该对象“是否为热对象”， 根据复杂的准则考虑删除的候选副本。图17中描述了在本优选实施 例中所用的删除准则(1800)。特别地，删除准则实现了需求到能力 的评估。\n应该注意，在本优选实施例中，删除和复制准则之间彼此是相反 的。也就是说，更新一个副本的情况是和第一次为基础创建一个新副 本是相同的。图16更详细地描述了在本优选实施例中所用的副本删 除处理(1500)。如果副本删除处理(1500)发现了删除一个副本的 原因，则副本管理系统简单地拒绝更新副本(即：更新该副本的生命 期限)。删除一个副本导致副本目录(656)的相应的更新。\n图14是副本创建处理(1300)的流程图。正如前面所提及的， 副本创建处理(1300)的目的是判断是否需要为请求的对象创建一个 新副本。当检查请求(1415)(图12)在(1300)步被接收时，副本 创建处理判断是否被请求的对象为热对象集合中的一个(1304)。如 果该对象是热对象，则一综合的不足检查在(1350)步被请求。这一 检查称为需求对能力检查，这在图17中进行了详述。另一方面，如 果该副本不是该热对象集合(1355)中的一个，则控制器确定还无时 间复制(1360，1370)，因此，也就没有副本被创建(1375)。但是， 在(1360)步，即使该对象不是“热对象”，控制器也可以确定创建 一个副本。例如，根据某些价格准则给某些被选择对象优先权，这样 可允许对有关如较高价格的对象优先复制。因此，在(1365)步，副 本放置算法如图15所示被调用。\n图17是描述检查需求对能力处理(1800)的流程图。按照(1830) 步，判断是否对某一特定对象(O(R))的预期需求(在1810步判 断)超过可用能力(在1820步判断)被形成。在(1830)步，如果 预期需求大于可用能力，则控制器把被请求的(热)对象看作是复制 候选对象，正如在(1831)步所示。在这种情况下，被请求的对象被 放于复制队列，然后副本放置处理(1400)被调用(如图15所示)。 另一方面，如果预期需求小于可用能力，则控制器确定还不是复制对 象的时间，如在(1835)步所示。\n应该注意，GREEN副本(1415，如图13(b)所示)的不足， 正好用作调节副本创建处理(1300)的触发。真正确定创建一新副本 是在(1830)步被检查的，并只有当预期需求(1810)，如图17所示 明显地超过可用能力(1820)时才可创建。正如前面所述，平滑需求 统计值被用来为每一个对象加强预测预定的需求。另一方面，服务器 的利用/意愿状态(990)(如：图6(b))及其服务器能力级被用来大 致预测服务器能力(如：余留的GREEN服务器的数)。应该注意， MON_REQUEST消息还可以被用来查询一GREEN服务器，以对其 剩余能力作粗略估计。对于控制器，这种估计只有当被转化为该对象 对副本作出评价的特定请求时才是有用的。如果专门地为该对象保 留，这将产生该服务器能提供更多的的放置数量。在本优选实施例的 图17中，如果该数(1820)小于有关被请求对象的预期需求(1810) 时，则作出一个创建新副本的决定(1831)。\n在副本创建处理确定对所给定对象需要创建新副本后，根据图15 中所述的副本放置处理(1400)被调用，以确定是否能找到这副本的 放置。\n图15是描述副本放置处理(1400)的流程图，该处理如步(1430) 所示，根据例如能力因子，实现查找目标全局服务器。除了查找目标 服务器外，副本放置处理(1400)如在(1420)步所示的还试图查找 源服务器，从此步开始复制过程。所以，如在候选源服务器和目标服 务器的步(1440)所示，控制器参与探测和会话过程。更可取的是， 如果选项如(1450)步所示未被接受时，随过程返回到(1420)步， 探测和会话过程会自然重复，以查找新的源服务器和目标服务器。探 测和会话过程是借助通过鉴于图18以举例方法所述的副本管理协议 所提供的查询功能(REP_QUERY/RQ_ACK消息)来完成的。例如， 在探测源服务器(1420)和目标服务器(1430)的过程中，副本放置 处理(1400)会话副本选项(1440)如：确定复制的信息流速率(和 其相关的带宽要求)。应该知道，被复制的目标可能在复制期间被转 换，例如，在图15所示的选项会话(1440)步的期间，要被复制的 目标可能被降级为较差的质量，类似地，该对象可能被编码为不同的 格式，或可能增加与该对象的原始内容相关或无关的内容。\n当接受了复制选项后，该过程前进到(1460)步，在此产生一个 复制请求，最好是，该复制请求(1460)被放置到某一当前未拥有被 选择对象的另一副本的GREEN全局服务器上。如果有多于一个这样 的GREEN全局服务器存在时，那么，按照本优选实施例，基于某些 价格准则如：与被请求对象相关的可用能力，优先给予的是最靠近的 全局服务器。\n应当注意，在本优选实施例中，预先不足准则(图13(b))在大 多数情况下将导致0个或1个GREEN副本(即，潜在的源服务器) 被留下。此外，可能找不到遗留的GREEN目标服务器。而且，应当 注意，在本优选实施例中，副本放置处理并不明确地在源服务器或目 标服务器上预订资源，由于这些原因，本发明中的优选实施例依靠授 权使用任何这种服务器(源或目标)的剩余YELLOW/RED能力。副 本放置处理(1400)依靠使用服务器的出界(out-of-bound)、超设计 能力(即YELLOW/GREEN能力)来放置复制请求，也就是说，如 果找不到被选对象可用的GREEN服务器的话，副本放置处理(1400) 被允许将复制请求(1460)放置到任何有能力的YELLOW服务器上， 为此，有必要增强服务器方面的接纳控制(1040)，以便区别复制放 置和请求放置。同时，如果没有剩余的GREEN副本可用，则副本放 置处理可能对复制请求进行排队(1460)直到当这种GREEN副本变 为可用时为止。\n回到图15，当源服务器和目标服务器被选择后，复制请求，如在 (1460)步所示，被放置到该两种服务器上。处理这一复制请求所必 需的信令在图18中以举例的方式更详细地被描述。在(1470)步， 控制器等待从完成复制的被选择的目标服务器上传来的肯定确认，然 后，在(1475)步，某一期满期限被赋予该副本，在此称为副本的生 命期限，它给全局服务器上的临时副本的生存强加了一个范围(可更 新的)，接着，在(1480)步，控制器更新其副本目录(656)，此后， 新副本变为可用(1490)以备将来放置之用。\n根据会话选项(1440步)，复制可能耗费时间。因此，按照本发 明，在复制期间放置的请求可能会被延期(时间上)、转交(给另一控 制器)、或者根据某些协议被控制器拒绝。\n本领域内普通技术人员将意识到在这一时间期间，已报告的各服 务器的利用/意愿状态可能会变化。一方面，可能当一个临时副本被创 建时(1470)，一个或多个服务器变为可用状态(即，GREEN)，因 此导致能力超过需求，在这种情况下，新创建的副本的生命期则决定 了供给过剩的持续时间。也就是说，正如所提及的，复制机理赋予了 它所创建的每一副本的终止期限，当某一副本超过了其终止期限时， 其全局服务器请求更新该副本的终止期限。如果这一努力没有成功， 则该副本可能从全局服务器上删除，从而可使其资源变为可用。另一 方面，也可能到新副本变为可用时，没有剩余的可用能力(即，找不 到GREEN服务器)，从而导致需求明显超过能力。在这种情况下， 在能力不足时的放置将触发额外的副本创建检查，由于这个原因，限 制任何特定对象的要创建的副本的最大数量是必需的。本领域内普通 技术人员将会意识到：新的检查请求按一预定数量的时间被排队，然 后，该时间过后，初始不足的条件被重新检查，以便来决定是否情况 依旧(也就是说，在排队期间，没有GREEN副本变为可用状态)。 很明显，如果该段时间太长，那么对这一对象的请求将被丢弃或转交 给另一控制器。\n图18描述了一个对象管理协议(1200)的实例，它可使控制器 (520)能在全局服务器上创建和删除临时副本。一旦控制器确定需 要并对一个新副本进行放置，则控制器开始查找源服务器(如：1720)， 然后与一个或多个这种服务器进行会话复制连接，这可表示为 REP_QUERY(2020)/RQ_ACK(2025)消息交换。REP_QUERY(2020) 消息中包含了要复制对象的对象标识符以及会话参数。\n当某一服务器(如：1720)接收到REP_QUERY消息(2020) 时，它应用接纳控制并决定是否接受该复制连接，该技术领域中的读 者将意识到：REP_QUERY消息(2020)在功能上与CID_QUERY 消息很类似。但是，如前面所述，需要区分放置请求和复制请求，以 便对复制请求提供有特权的接纳控制(即YELLOW接纳)。在对复 制请求(2020)实施有特权的接纳控制后，每一潜在的源服务器(如： 1720)通过RQ_ACK(2025)消息向控制器传递该接纳的反馈信息。 应该注意，服务器的每一这种反馈信息可能表明：(i)控制器(520) 接受在REP_QUERY消息(2020)中所提供的会话参数，(ii)会话， 或(iii)控制器(520)拒绝在REP_QUERY消息(2020)中所提供 的会话参数。\n在此时间期间，控制器还通过使用另一 REP_QUERY(2021)/RQ_ACK(2026)消息交换的方式探测前面所述的 一系列有可能的(见1730)目标服务器，每一潜在的目标服务器(如： 2010)对REP_QUERY复制请求实施有特权的接纳控制(如以上所 述)，并通过其RQ_ACK(2026)消息向控制器(2000)传递其接纳 的决定。\n如同CID_QUERY消息放置的方式，控制器(520)从源服务器 和目标服务器搜集RQ_ACK消息(如：2025和2026)，然后从候选 的复制放置中作出选择，类似地，如果没有接受到候选的复制位置， 则控制器根据其复制策略(见1765)(图12)实施进一步的探测。\n接着，一旦控制器(520)选择了源服务器和目标服务器， REP_LISTEN消息(2040)被发送到目标服务器(1730)，该 REP_LISTEN消息识别要被复制的对象(如：对象01)、源服务器(如： 1720)和目标服务器(1730)。此外，该REP_LISTEN消息(2040) 包含了副本的由控制器决定的生命期。如前面所述，该生命期被用来 决定临时副本在此服务器上的寿命并允许不再使用时删除其内容。 REP_LISTEN消息(2040)导致全局服务器(2010)等待和监控 REP_LISTEN消息(2040)中所标识的服务器(如：1720)来的复 制连接。目标服务器为这一复制连接设置资源，然后通过RL_ACK 消息(2045)向控制器(520)确认准备好。在目标服务器(1730) 通过RL_ACK消息(2045)确认准备好后，控制器(520)向被选择 的源服务器(2005)发出REP_PLACE消息(2055)，该REP_PLACE 消息(2055)识别要复制的目标、源服务器(1720)和目标服务器 (1730)。该REP_PLACE消息(2055)指示源服务器启动向目标全 局服务器的复制连接。源服务器(1720)安排和设置对目标服务器 (1730)的复制连接。\n在源服务器(1720)设置其复制连接后，源服务器通过RP_ACK 消息(2075)向控制器(520)确认复制连接开始。同时，通过使用 一个或多个REP_TRANSFER消息(2060)，按前面会话的参数开始 内容复制。每一REP_TRANSFER消息(2060)包含了对目标服务 器上零散的内容进行重建所必需的数据(如：顺序号，字节数等)。\n在内容被复制完后，目标服务器(1730)通过REP_COMPLETED 消息(2090)向控制器(520)宣布新副本的创建。REP_COMPLETED 消息包含了被复制对象的对象标识符。REP_SETLIFE消息(2085) 被控制器用来向拥有临时副本的全局服务器传递更新以及其相关的新 期限。控制器一直等待(1555)到上述的全局服务器通过RS_ACK 消息(2095)确认更新为止。然后，控制器更新(1480)其副本管理 目录(656)以备将来依靠这一在全局服务器(1730)上新近创建的 临时副本进行以后的放置。\n应当注意，新的临时副本的创建在全局服务器上并不预定资源。 而是使用按需复制以增加在以后对同一对象的请求时查找可用能力的 可能性。\n由于副本不是永久的，而是与一生命期相联系，复制机制对每一 创建的副本赋予了一个终止期限，当某一副本的终止期限到期时，它 的全局服务器请求更新该副本的终止期限，如果这一努力不成功，则 副本可能从全局服务器上被删除，从而使其资源变为可用。\n按照本优选实施例，在对某一对象的需求有持续的且明显的减少 的期间，副本管理系统将调整能力，在本发明中，副本管理系统自主 地决定是否应该删除一个副本。特别是，每当服务绑定被终止时，与 该服务绑定相联系的服务器向控制器发送CID_COMPLETED消息。 除了其它事以外，该CID_COMPLETED消息导致控制器对该特定副 本实施初始供给过剩检查。此外，初始过剩检查(1505)(图13(a))， 也可以在当请求更新某一副本的生存期时，由某一服务器触发。\n更好地是，过剩检查的实现用于决定某一特定对象的可用能力是 否明显超过预测需求，特别地，本优选实施例能识别各种过剩的情况， 如(但不仅限于)：经过一个或多个副本的低利用、查明存在的对象 副本不是“热对象”，以及副本的生命期已到。这样，本领域内普通技 术人员将会理解热对象的最大数量和临时副本的寿命的相互作用。如 果临时副本的寿命选择的太长，则可能不再是热对象的副本可存在于 全局服务器上，而当前刚成为热对象的副本也许正期待可用的GREEN 全局服务器。\n图13(a)描述了本优选实施例所用的初始过剩检查(1505)。如 果一个临时副本的生命期查明已到期(1510)，则该副本将被做删除 检查，在这种情况下，副本删除过程(1500)在(1515)步被调用， 用来完成较综合的分析。否则，不采取任何行动(1599)。\n图16描述了副本删除过程(1500)的流程图，该删除过程用来 决定某一被检查的副本是否应该被删除。相反地，副本删除过程 (1500)还决定某一副本是否应该被更新(1535)。副本删除过程 (1500)首先检查该副本是否与一热对象(1525)相联系，在这一点 上，控制器或者可以拒绝更新而删除该副本，或者接受更新而延长该 副本的生存期。一方面，如果该副本是热对象，则一个综合的需求对 能力的检查被调用(1530)，如在图17所述。另一方面，如果该副本 不是热对象(1525)或者在需求对能力检查中(1530)被发现处在过 剩状态下，则该副本被认为是删除的候选副本。\n按照当前的实际应用，真正的删除可被推迟(1565)到该副本被 发现连续两次是删除的候选副本(1570)时。本领域内普通技术人员 将会看出该实施例是在参考书“操作系统概念(Operating Systems Concepts)”(Prentice Hall，Peterson and Silberschatz)中所述的第 二次随机更新算法的一个实例。如果这是该特定副本的第一次随机经 历(1590)，则该副本临时被更新(1540)。本领域内普通技术人员将 意识到第二次的生命期(1550)可能比第一次的要短。REP_SETLIFE 消息(2085)(图18)被用来向拥有该临时副本的全局服务器传递该 更新以及与其相关的期限。控制器一直等待(1555)到该被讨论的全 局服务器通过RS_ACK消息(2095)(图18)确认更新为止。如果已 经给过该副本第二次随机经历，则该副本将在(1570)步被删除。然 后控制器丢弃该副本的更新并导致该全局服务器删除该副本。当删除 一副本的决定被满足(1570)时，副本目录也被更新(1580)，因此 随后的放置应利用这个副本。应该注意，在某些实现过程中，副本数 据结构需要保护，因为有多个线程或过程访问它。\n本领域内普通技术人员将会意识到：可以采用与相对于一次一个 副本的方式不同的其他的机制形成能力。特别是，能力形成问题代表 适应率控制问题，因此，最流行的惯例认定使用不对称补偿方案。例 如，可以使用成倍增加(如：第1次创建1个副本，第2次创建2个 副本，第3次创建4个副本，等等)和线性减少(如：第1次删除1 个副本，第2次删除1个副本，等等)配对的方案。也可能使补偿工 作(如：要创建的副本数量)与需求的增长相匹配。在这种方法下， 要创建的副本数量由基于过去和将来的需求差别来决定(如Manohar， N.等人在“Applying Statistical Process Control to the Adaptive Rate Control Problem”，Proc of SPIE MMCN’98，January 1998文章中所 述)。不管怎样，很明显，副本的最大数量限制是可取的，以便限制 复制代价。\n此外，本优选实施例中的需求和能力形成机制的分布式实现是可 能的。例如，在某一实施方案中，控制器机能可能存在于每一服务器 上，然后，代理控制器为该服务器执行需求和能力监视任务，并且当 超过临界阀值时，控制器开始依靠使用全局服务器。特别是，各不同 的控制器可以使用相同的全局服务器。\n该技术领域中的人员将理解：在此所述的该触发控制的实现对特 定的环境可被优化，这种环境是指需求和地理模式是知道的或可以稳 定地被预测。\n本发明有很多有用的应用，例如，正如所提及的，本发明的系统 方法可以被支持广播内容提供如：有线电视网的因特网服务提供商 (ISP)作为增值服务，出于演示的目的，动态使需求与有线网络服 务器的能力相匹配。当需要时，根据呈现给ISP的对那些内容的需求 特点，ISP将临时副本(该有线网络内容的)放到自己的全局服务器 上，在此讨论其中的几种变化。\n例如，当支持多广播内容提供商时，本发明还可用来提供ISP资 源的统计共享(也就是，全局共享的服务器)，这样，ISP控制器将按 照某些价值衡量标准如：利润或内容提供商最大损失保护概率，ISP 的最大利益，管理复制请求的分配。\n在实现某特定利益时，每一独立的内容提供商运行一台称为防火 墙后的代理控制器的服务器。该代理控制器为内容提供商完成需求和 能力的监视任务，并且当超过了临界阀值时，该代理控制器将复制请 求放置到ISP的控制器上。然后，该ISP控制器对各未处理的复制请 求进行仲裁，以决定哪些复制请求被分配到全局服务器上。特别是， 同一全局服务器可被不同的代理控制器共享。\n本领域内普通技术人员会意识到为了安全的原因，内容提供商可 能不愿意泄露也不允许另一方访问其内部使用的统计信息。由于这个 原因，可以想像，内容提供商应该允许直接请求特定副本位置到ISP 全局服务器上。此外，这种请求可以是附加有条件的(由内容提供商 而不是由控制器)以满足特殊要求如：目标全局服务器的地理位置或 能力。然后，ISP控制器将尝试确定满足这种要求的一个特殊服务器 的位置。例如，某一特定的内容提供商可以发出某一复制请求如：“在 以下5分钟内给我提供以下内容的副本，并且放置该临时副本到美国 东南部的HIGH能力的服务器上。”\n此外，ISP们可以达成协议进行合作，允许某一ISP将其复制请 求转交到具有合适的全局服务器的其它的ISP那里。例如，在某一ISP 的全局服务器中没有一台满足相对于某一内容提供商发出的请求的要 求的情况下，则该ISP将会把复制请求转交给这些友好的ISP。\n另外，这种复制请求放置的拍卖可以通过中间一方来实现，然后， 这一中间方按照某种价值衡量标准如：成本或期满时限，将复制请求 转交到最有能力的或合适的一方。\n本领域内普通技术人员将会意识到：某一副本被存放到一个不再 能满足需求特性的全局服务器上是可能的。所以，副本迁移管理因执 行周期明智地检查而被增强，该检查负责稳定性及细调整个系统上临 时副本的分布。该副本迁移过程完成垃圾收集以及临时副本的放置和 数量的优化，该副本迁移过程以一种类似于垃圾收集过程的方式被调 用。副本迁移过程检查所有临时副本列表并找出那些具有低利用状态 的副本。\n副本迁移过程也许不能确定在各地理区域间移动副本是否是有效 率的(按照某些价值准则)，如：当某一热对象支配的地理区域变化 的情况(例如，当来自客户机的请求从东海岸转变为西海岸时)。但 是，由于增加了预测的需求的地理相近性，所以副本迁移可被用来减 少网络花费。例如，如果整个系统能力是低的并且预测需求的分析发 现将来需求特性的变化，则某一已经放置好的临时副本从一台全局服 务器上移动到另一服务器上可能是可取的。特别地，虽然早期需求已 经导致将某一临时副本被放置到地理区域G1上，但是地理区域G3 的预测需求可使得该临时副本从G1移动到G3是可取的(见图8)。 因此，根据某一能预报预测需求的价值衡量标，通过比较当前位置和 建议位置，某一副本向另一不同的全局服务器的移动被触发。副本迁 移过程依靠各种的启发，如：临时副本可能根据某些设定的准则从某 一全局服务器被移动到另一服务器上。另外，位于不同的全局服务器 上的两个临时副本可被叠合(合并)成位于单一全局服务器上的一个 副本。例如，合并两个或多个临时副本以便将它们合并后的放置特点 (如：利用和需求统计信息)移动到另一服务器上有时也许是有用的。 另外，这一移动可能基于某些设定的准则如：全局服务器对需求统计 信息的适合性，由于这个原因，本发明将副本的合并看作是一种附加 的副本迁移设计。\n将副本(临时的或不是)迁移到另一副本(临时的或不是)，也就 是将某一服务器的一个副本卸下放置到另一服务器上也是另一需要。 例如，开放某一特定的全局服务器上的能力，或者将多个服务器上稀 少利用的临时副本合并成一个低利用的永久副本应该是所希望的。\n还应该知道，副本迁移尺度要求根据过去放置目标的仔细地触发 控制，以避免副本统计的不稳定性。本领域内普通技术人员将意识： 除此之外，或作为上述技术的替代，可以使用诸如在线过程优化和神 经网络技术，以实现自调节的控制以及评价和控制上述迁移启发的鲁 棒性。\n尽管在此特别展示和描述了有关本发明的作为说明和预先形成的 实施例，然而，那些熟悉本技术领域的人们都知道，其中形式和细节 上的前述和其它改变均可作出而不脱离本发明的精神和范围。本发明 的精神和范围仅由所附权利要求书的范围来限定。