专利名称：：一种基于互联网事件驱动机制编程模型的建立方法
技术领域：
：本发明涉及一种基于互联网事件驱动机制编程模型的建立方法，属于互联网应用开发领域。其中包含的主要技术有分布式计算、互联网通信、远程事件驱动模型、多播技术以及远程消息机制等。
背景技术：
：事件驱动机制已被广泛应用于普通程序和分布式程序设计当中。作为一种编程模型，事件驱动提供了一个注册方式用以辅助系统监听潜在可能发生的事件；并在事件发生后，立即利用通知机制使得关心事件发生的系统对事件作出及时响应。如果没有这个机制的支持，开发人员的编程工作量会大大增加，同时系统效率也会下降。然而，在当前互联网开发环境当中并不存在这样的事件驱动机制。这致使互联网开发变得复杂而且效率低下。在一些普通分布式系统当中，事件驱动机制是存在的，即远程事件驱动机制。这个机制通常基于远程过程调用(RPC)1或者远程方法调用(RMI)2。在实现远程事件驱动机制时，潜在的远程事件会被记录在注册服务器上并与监听系统相关联。当一个远程节点上发生了注册事件时，这个远程节点会主动调用与该事件相关联的监听系统。监听系统则激发所处节点相关程序来完成对事件的响应。但这个机制在互联网应用中却不存在。开发人员在需要响应潜在互联网事件时，不得不采取投票方法3来监测事件的发生。投票方法本身是一个低效方式，系统不得不为此付出过多额外代价；开发人员编程工作也会增加；还必须为投票方法设计恰当访问周期，而这个周期必须和具体应用相结合才能获到符合要求的结果。当系统处于波动状态时，这个周期不是固定的，这也为探测访问周期增加额外负担。即使模拟访问周期能够相对准确获得，但由于事件本身的不确定性，仍然需要消耗资源从而达到跟踪潜在事件并在发生后能够及时响应。除此之外，开发人员编程工作量也会增大，程序本身也不够简洁。当前互联网系统没有采用事件驱动机制是符合互联网发展初期应用环境的特征，是对当时计算环境的适应。而这种对当时环境的适应，也造成了在当前互联网中采用事件驱动机制的障碍。现对此进行简要解释。第一，早期和当前互联网以互联网服务器为绝对中心。无论是早期互联网还是当前互联网都是以互联网服务器为绝对中心。所有计算资源均来自于互联网服务器；互联网计算的全部特征都被服务器资源所左右。这种对服务器绝对依赖的方式在早期互联网应用环境中是合理的。当时，访问互联网的客户端计算能力有限；即使计算能力强，由于网络瓶颈以及安全问题也造成互联网计算难以利用除了服务器以外的其他计算资源。事件驱动机制本质上是建立在多个相对独立计算模块或者节点均可以主动方式进行交互的条件上。互联网服务器绝对中心的计算模型本身与远程事件驱动机制需要的计算环境是不一致的。第二，早期互联网服务器发布资源主要以更新缓慢的静态资源为主。在早期互联网服务器待发布资源有限，其更新也不频繁，远低于客户端访问的频率。在这种情况下，新数据发布或者更新事件无需产生并通知客户端。另外，早期互联网应用是以静态资源为主。基于静态资源的互联网应用当中，除了数据发布、更新和删除等有限事件外，没有更多的事件需要跟踪。第三，早期和当前互联网服务器计算资源有限。无论是早期还是当前互联网系统，以服务器为中心的模式导致互联网计算资源在客户端规模庞大时会变得有限。为了以有限的资源应付潜在的大量用户访问，不得不减少非主要计算的资源消耗。远程事件驱动机制不但对服务器本身资源消耗具有压力，同时要求客户端的计算模型随之进行改变。在客户端没有改变的情况下，服务器设计时也把事件驱动机制省去也是可以理解的。这实际上形成了一个两难局面。省去了事件驱动机制，投票机制对服务器的压力就会增加；而使用事件驱动机制，服务器同样必须付出额外计算压力。早期互联网设计者在衡量了两种情况下服务器可能付出的压力后，选择了不实现事件驱动机制。这和当时服务器上事件种类少，发生不频繁也有关。第四，早期和当前互联网不存在持续保持的网络连接。由于潜在事件发生时机事先无法估计，这就要求在分布式环境中不同节点之间保持持续的网络连接。一旦被跟踪事件发生，节点之间可以及时沟通以响应事件。然而，互联网通行的通信协议HTTP要求每个连接的生命周期有限，从而保证服务器有限连接资源能够用来应付潜在客户端的访问请求。在没有持续网络连接情况下，使得远程事件机制的实现在网络资源上受到了限制。即使潜在事件发生，有限的网络资源造成事件通知机制无法及时运行。第五，早期和当前互联网不存在适当的多播机制。作为互联网计算的中心，通常互联网服务器事件的发生会有众多个客户端关注。在这样的前提下，要求互联网服务器具有一个高效的多播机制以减轻互联网服务器因通知客户端带来的压力。然而，在当前互联网系统中，这个多播机制是不存在的；一旦存在一个事件驱动机制，服务器不得不付出计算资源通知所有对事件关注的客户端，从而导致计算压力过大。这也是当前互联网没有事件驱动机制的原因之一。第六，纯粹瘦客户端模式造成客户端无法参与互联网计算。造成当前互联网系统无事件驱动机制存在的另一个主要原因是纯粹瘦客户端模式。所谓纯粹瘦客户端模式指的是客户端在任何情况下只以发送请求和接受回应的形式访问服务器。而这种形式本质上不是对互联网计算的参与，只是对互联网计算的引发。所有计算完全是有客户端请求下在互联网服务器上进行的。事件驱动机制是建立在对不同计算节点共同参与计算的基础之上。但是由于客户端不能参与互联网计算，在客户端与服务器之间以及客户端之间都不能产生基于协作计算，因此事件驱动机制在早期和当前互联网中都是无法建立的。
发明内容本发明的目的在于提供一种基于互联网事件驱动机制编程模型的建立方法，其在互联网应用中为开发人员建立基于远程事件驱动机制和编程模型，简化互联网应用开发代价，并为建立更高效互联网应用作出贡献。本发明的技术方案为一种基于互联网事件驱动机制编程模型的建立方法，其步骤为1)采用TCP/IP对等协议模式使计算节点具有接收请求和发送请求的能力；2)在计算节点之间建立直接对等的交互协议；3)在计算节点上建立基于消息的事件监听机制，用于接收数据；4)建立动态集群，并在动态集群内采用数据多播机制进行数据传输；所述动态集群为基于共同需求的计算节点在某一个时刻形成的计算资源协作共享模型；5)监测所述动态集群内的节点，将事件发生节点的数据通过所述数据多播机制传输给其它节点；6)结合软件工程技术，根据传输的数据类型建立事件驱动编程模型。所述计算节点包括客户端和服务器端。所述计算节点之间直接对等的交互协议的建立方法为-1)建立网络连接监听机制；2)通过IPv6或NAT穿越技术实现互联网上任意节点的直接连接；3)根据具体互联网应用特征，建立不同的客户端和服务器端对等交互的协议。所述方法中利用异步编程模型结合TCP/IP协议完成所述建立基于消息的事件监听机制。所述基于消息的事件监听机制的工作方法为在获得相关远程事件消息后，启动本地事件驱动机制把远程事件转换成本地事件，来驱动本地相关系统对远程事件予以响应。所述相关远程事件包括消息远程事件、文件远程事件、字节远程事件和对象远程事件。所述数据多播机制为利用BT协议形成的拓扑结构进行轻量级数据多播，其方法为1)采用BT协议的跟踪器监测动态集群中计算节点的状态，所述节点状态包括节点是否处于集群中、节点是否对某个事件关注、节点是否为超级节点、节点是否已获得某个事件；2)对于处于集群中节点，所述跟踪器均衡分配多播任务，其方法为首先为传输数据设置唯一标识；然后所述跟踪器将确定出的超级节点作为种子节点，通过并发连接向其它节点传输数据；节点检查接收到的数据的标识，如果出现重复，则停止传输给该节点的并发连接节点；否则传输给该节点的并发连接节点继续多播。所述传输数据上标识有曾经经过的节点，当出现当前到达节点与轻量级数据经过的节点重复时，则停止传输；否则，继续多播过程。所述数据类型包括消息、文件、字节和对象。所述事件驱动编程模型包括消息发送及相关事件、文件发送及相关事件、字节发送及相关事件和对象发送及相关事件。本发明的方法流程如图2所示，其主要内容为第一步，为弥补计算资源不足，建立所有节点皆可参与计算的互联网环境。建立远程事件驱动机制的前提是解决当前互联网对服务器绝对依赖的问题。这种运行方式使得计算资源严重受限于互联网服务器。为弥补不足，单独增加服务器计算资源的方式是需要的，但并不是有效的做法。当面对潜在大量客户端并发请求以及重量级数据传输的压力时，上述方式提供的计算资源仍然是不足的。完全解决互联网计算资源不足的问题，只有采取把所有处于互联网环境中的节点都加入互联网计算，并利用它们自身的计算资源。为完成上述工作，需要以下几个步骤的工作。(1)改变纯粹瘦客户端服务器模式。当前互联网纯粹痩客户端模式是造成互联网计算资源不足的主要原因。这个问题的解决是增加互联网计算资源的关键。在早期互联网发展阶段，服务器资源是互联网计算资源的唯一来源。但是随着计算设备和通信技术的发展，处于互联网上的计算节点在计算能力以及带宽上都具备了可利用的能力。这些计算节点如果仍然以纯粹瘦客户端模式在互联网应用中出现，只会对互联网资源产生消耗。随着互联网应用的普及，这种纯粹瘦客户端会越来越多，对互联网资源的争夺也会越来越激烈。如果不能改变这种模式，互联网的发展只能依靠服务器端出现强大的计算能力。这对大多数互联网应用来说意味过高成本投入，是不现实的解决方案。(2)改变客户端和服务器端交互协议。当前客户端和服务器端的交互协议是以客户端发出请求并等待回应，而服务器端接收请求并产生回应为基本工作模式的。这种模式将所有计算代价由服务器来承担；客户端不参与计算。本发明改变了这种协议，尽量把计算由服务器端转移到客户端，以减轻服务器计算负担。这个改变的主要原则是将请求回应的形式转变为对等模式。要实现这个模式，需要赋予客户端以接收请求的能力而赋予服务器端以发出请求的能力。作为TCP/IP协议来说，它本身就是一个对等协议。但是由于基于TCP/IP的互联网应用协议HTTP为了适应早期互联网的具体环境，把TCP/IP协议改成了客户端对服务器端的单纯请求回应模式。本发明借助于当前计算设备和通信技术的发展，将这个模式变成了对等模式。然而在互联网上达到这样的目的要解决三个重要问题，才能得到适合互联网应用的对等协议。第一，建立网络连接监听机制。HTTP协议只在服务器端具备网络监听机制，而在客户端没有。这是只有服务器端才能被访问而客户端主动访问的原因。本发明中，必须赋予二者具备网络监听的能力。第二，实现互联网上任意节点的连接。互联网由于地址空间和安全因素，并不是所有节点都能够建立直接的网络连接。这个障碍可以通过IPv11或者NAT穿越技术12来解决。第三，根据具体互联网应用特征，建立不同的客户端和服务器端对等交互的协议。由于互联网计算的复杂性，不同性质的应用客户端和服务器端交互方式千差万别。为了应付不同场景，本发明在建立了客户端和服务器端的连接之后，还提供了二者之间对等的消息、文件、字节和对象基本传输方式，开发人员基于此，定制成适合具体应用的的交互协议。(3)建立客户端之间交互协议。除了在客户端和服务器端建立新型交互协议以外，客户端之间也可以产生协作。在当前互联网环境中，客户端之间不存在任何交互。其交互完全是通过服务器辅助来间接完成的。这也增加了服务器的计算压力。本发明通过在客户端之间建立直接交互机制，从而为客户端之间形成动态集群计算提供基本条件。这对于减轻服务器端计算压力以及增加整个互联网计算资源是至关重要的。要实现这个目标，同样需要解决监听机制、连接以及结合具体应用三个问题。这三个问题当中，在客户端之间建立交互机制相比于客户端和服务器端来说会更困难。其主要原因是客户端会更多地受制于互联网有限地址空间和安全因素的影响。如果使用NAT穿越技术，其复杂程度会高于在客户端和服务器端建立连接。这是由于每个服务器通常具备可访问互联网地址，而以客户端不具备互联网访问地址或者处于NAT保护中的可能性要高。(4)建立服务器端之间交互协议。与当前客户端交互模式类似，服务器端之间的交互是通过客户端辅助来完成的。需要指出的是，当前无论是客户端之间的交互还是服务器端之间的交互都是在人工参与下间接完成的，并非通过本发明提及的动态集群在上述节点之间自动完成。这种基于人工参与的计算只能形成轻量级低效率的交互，对于重量级高效率复杂计算是无法应付的。为了解决服务器之间低效交互问题，同样需要在这些服务器之间建立直接交互。为此，监听机制、连接以及具体应用特征也需要考虑。相对来说，上述问题的解决在服务器之间就容易得多。这主要是互联网服务器通常都具备独立的互联网地址供其他计算节点访问，同时服务器性能一般要大大强于众多客户端。实际上，在建立连接后，针对不同应用采取具体协议是最为困难的。本发明为这个工作更有效完成建立了基础。(5)针对具体应用，建立相应交互协议。真正实际的交互协议必须和具体应用紧密结合，根据具体应用的特征釆取相关算法或者解决方案。互联网应用按照传输数据的特征大致可以分为三类，即轻量级应用4、与时序无关重量级应用5以及与时序相关重量级应用6。轻量级应用适合于一般的即时通信和商业系统；与时序无关重量级应用适合于文件共享、电子邮件、BBS和普通Web应用等；与时序相关重量级应用适合于音频视频流媒体数据为主的应用系统。不同应用的性质，对计算资源的要求以及工作模式都是有差别的。但由于本发明所依赖的分布式基本结构发生了本质变化，从而导致上述不同应用能够在更丰富的计算资源支持下工作。详细算法可参考相关文献以及本人其他发明。第二步，建立基于消息的事件监听机制。计算资源的紧缺以及计算节点之间交互的限制造成了远程事件驱动机制无法在当前互联网系统中得以实现。通过对互联网应用层基本结构的改变，上述两个主要问题得到了解决，即互联网事件驱动机制是建立在计算资源丰富以及计算节点之间自由交互的基础上。在这个前提下，就可以在每个计算节点上建立事件监听机制。这个机制本质上是一个轻量级数据(消息)等待接口。这个接口可以通过利用异步编程模型7结合TCP/IP协议来完成。需要注意的是，在获得相关远程事件消息9后，需要启动本地事件驱动机制把远程事件转换成本地事件，来驱动本地相关系统对远程事件予以响应。当前主要操作系统以及开发工具都支持本地事件驱动机制，可参考有关材料完成这个工作。第三步，建立基于轻量级数据的高效可靠多播机制。在本发明所依赖的计算环境中，应用都是动态集群来完成的(本发明采用了在复杂网络系统8中数据复制、网状多播机制5，6、动态筛选节点5以及基于复杂网络理论的路由算法9等手段来建立动态集群)。所谓动态集群是基于共同需求的计算节点在某一个时刻形成的计算资源协作共享模型。这个模型内部通过计算资源的共享来达到提高系统计算性能的目的。建立动态集群的方法和在稳定环境下的集群完全不同。流网协议是其中重要解决方案，将其简单地归纳如下建立基于社会网络13的路由算法。这个路由方案是建立在社会网络或者复杂网络13基础上的资源寻找算法。由于社会网络本质上是计算节点通过互联网上用户社会属性而建立起来的符合互联网资源分配规律的拓扑结构，恰当地利用这个网络就能够完成对计算资源的有效寻找。在利用社会网络进行路由搜索时，主要涉及结构化和非结构化路由技术的结合问题。结构化路由技术的突出特点是能够对任何资源(稀缺或者流行)在确定有限时间内获得路由结果，但是这样的结果是建立在严格约束条件下。而这个条件当前互联网环境难以得到保证。非结构化路由技术建立在互联网自然形成的拓扑结构(即社会网络)之上，并没有对存在的互联网环境有任何强制要求。在这样的基础上要保证快速获得搜索结果，必须要求对具体的应用以及相应的拓扑结构有深入认识才可达到。但即使如此，非结构化搜索在路由公平性的保证仍然不足，同时对路由压力的分担也困难。鉴于上述原因，可以把上述二者恰当结合。由于社会网络中存在群落，群落代表着相对稳定的计算环境，接近于结构化路由所要求的条件。这样，可以采取在整个互联网中进行非结构化路由，而在群落中进行结构化路由。通过上述方法，路由算法就做到了有效寻找流行资源以及保证对稀缺资源的路由公平。建立动态集群中的事件驱动机制。动态集群形成的基础之一就是相互之间交互是以事件驱动为前提的。无论是一个节点请求建立连接、发起数据传输以及关闭连接等等基本行为都是通过事件驱动机制来完成的。这与传统互联网以投票为主的方式截然不同。而当建立起动态集群的基础之后，这个事件驱动机制就形成了基本框架。再结合高效的轻量级多播机制，就可以形成一个基于消息的事件驱动机制。这个机制能够适应互联网动态变化的特征，保证事件驱动机制在高效稳定可靠大规模环境下工作。这个机制的实现提高了互联网计算节点之间的交互效率，避免了投票机制给系统增加的压力以及对系统变化迟钝反应。事件驱动保证了关注者能够在事件发生前不用付出额外代价进行投票；同时，在事件发生后，能够即刻作出反应。由于这个集群并不是稳定的，而是处于不断变化当中。这种变化包括计算节点的加入和离开，也包括计算节点本身状态和行为的改变，还包括计算环境的改变以及计算节点性质的变化。对于动态集群这样一个特殊分布式计算环境来说，这些变化都是在某一个局部首先发生；这些局部状态的变化可能影响整体计算的性能。为此，多个节点都会对某个动态变化予以关注，并在变化发生的情况下进行及时反应。这样就形成了对事件驱动机制的需求。而局部状态变化要反映到全局，需要一个可靠的多播机制来完成。这也是互联网远程事件驱动机制的必要需求。这个多播机制需要完成下述工作。(1)使用轻量级数据表示事件以及相关状态。远程事件驱动机制的关键在于事件在某个局部发生后，能够及时使局部状态转化为更大范围甚至是全局状态。通常表示这个状态的数据是小的。即使一个系统中状态过多，其对应的表示在一个真实系统中也可以用轻量级数据描述。所以在考虑为事件驱动服务的多播系统中，只需考虑轻量级数据即可。这减轻了多播系统的设计难度。(2)轻量级多播系统要考虑的问题。首先是分散多播压力。当互联网多播系统面临的节点规模大，即使是轻量级数据多播，采取简单一对多的通知策略也会对事件通知节点造成计算压力，所以必须考虑适当手段以减轻这个压力。其次，要考虑对动态环境的适应。互联网应用的另一个特征就是计算节点的动态特征明显。除了为系统无偿贡献资源的服务器(对等服务器)以外，其余节点都是在用户控制下参与互联网计算的。当用户认为一个互联网计算已经满足其要求或者对其没有意义时，就可以随时退出该计算。另一方面，一个计算节点也可以在互联网计算过程中随时加入。这两个因素都会造成互联网计算的动态性。对于多播系统同样如此。在多播进行的过程中，处于多播系统中的节点并不处于稳定状态。这些动态特征会严重影响多播的可靠性。再次，要考虑对即时性的控制。事件驱动系统一个重要特征就是要求事件通知的即时性。当多播系统规模大时，即时性的保证就会出现问题。保证大规模多播系统的即时性是保证远程事件驱动机制建立的重要需求。最后，对可靠性的保证。可靠性在轻量级多播系统中主要指的是数据在动态环境传输过程中的顺序一致性以及容错性。当多个事件接近并发地发生时，多播系统必须保证事件在传输到各个节点时符合事件发生的原始时间顺序。对于大规模分布式系统，事件的顺序容易在多播过程中发生混乱。容错性在一个动态变化频繁的分布式系统中是必须做到的，以防止事件多播不能保证覆盖所有相关节点。(3)利用BT协议实现轻量级数据多播系统。针对上述问题，本发明采用了基于改进BT协议的多播系统。BT协议本质上是一个重量级数据多播协议。之所以考虑利用BT协议，主要是其运行环境与本发明环境是一致的；BT协议对于动态环境的适应方式值得借鉴。针对事件驱动系统只关注轻量级数据的特征，本发明必须对其进行改进，使其更适合轻量级数据的多播。图1说明了利用BT实现轻量级数据多播基本方式。A.使用跟踪器监测动态集群节点状态。BT协议中的跟踪器是专门用来收集一个潜在动态集群中所有节点状态的服务器。在本发明中，这个服务器可以通过布置中心服务器来实现；在本发明中，这个中心服务器的最大特点是能够主动与系统中计算节点联系，而不是总是处于被动等待计算节点汇报自身状态的地位。这个特点导致跟踪器可以成为基于BT的一个事件触发节点。当需要和一些计算节点联系时，能够主动发送数据或相关状态，而无需被动等待。比如，跟踪器在本发明中被用来评定超级节点，并据此将这些节点作为轻量级数据多播的起始；这个工作需要有跟踪器以主动的方式联系超级节点。对于用来进行事件驱动的轻量级多播系统来说，需要监测的状态包括节点是否处于集群中、节点是否对某个事件关注、节点是否为超级节点10、节点是否已获得该事件等。这些状态都会为事件多播系统的质量起到关键作用。在对系统中节点状态把握之后，才能对轻量级多播任务压力进行合理分担，提高多播效率和可靠性。B.利用BT协议形成的拓扑结构进行轻量级多播。BT协议是用来进行重量级数据传输或者多播的。为了在高动态环境在保证重量级数据高效多播，BT协议采取了一系列方案，如节点选择和数据片段选择等。BT协议的本质正如前面所述，是基于互惠策略计算资源共享来达到重量级多播的目的。无论是进行节点选择还是数据片段选择、或者互惠原则，其重要目的是实现应用层拓扑结构和网络层拓扑结构的匹配。所谓应用层指的是根据具体应用的需要建立起来的数据交互层；网络层指的是独立于任何具体应用基于网络的数据交互层。应用层建立在网络层之上；任何应用层的数据交互最终都必须在网络层上传输。但是，应用层计算节点之间交互形成的拓扑结构与具体应用场合直接相关，与支持网络传输的路由之间拓扑结构没有任何直接联系。当应用层拓扑结构与网络层拓扑结构严重不匹配时，会使应用层上的数据交互效率低下。应用层交互性能的高低严重依赖于它本身的拓扑结构与网络层拓扑结构的匹配程度。BT协议的主要作用就在于通过一系列手段实现了它们之间的近似匹配。通过BT协议从交互开始后一段时间的作用，所有参与重量级数据传输的节点之间会形成一个与网络层拓扑结构近似匹配的应用层。正是这个匹配保证了重量级数据多播的效率。本发明的运行环境也是基于大规模互联网，节点之间形成了基于具体应用场合的交互，即应用层。但是这个应用层拓扑结构只有通过BT协议的辅助才能与网络层拓扑结构形成近似匹配。与此对应，本发明所建立的互联网系统以重量级数据多播为主，并以BT协议为多播解决方案，这为形成与网络层拓扑结构的匹配提供了条件。对于轻量级数据多播来说，完全可以利用在重量级数据多播过程中形成的应用层拓扑结构。由于这个拓扑结构的形成经过了BT协议的有效调整，在进行轻量级多播时也会保持高效率。C.不对基于BT协议的并发配合节点数量作任何限制。传统的BT协议对节点之间的交互时并发数量有一个限制，通常为四个。这个限制对于大多数互联网上的普通节点来说是正确的。但是，对于本发明的互联网系统，却不是合适的选择。正如前面所说，本发明所建立的互联网系统不仅仅包括普通计算节点，更包括传统的服务器；这些节点是形成超级节点的主要候选者。这些服务器通常拥有丰富的计算资源，可以并发建立远超过四个的多播连接。因此，打破这个限制会使得BT协议运行的节点资源被尽量充分利用，提高了重量级数据多播效率。D.跟踪器根据监测确定超级节点。在BT协议中，跟踪器的职责是向新加入系统的节点返回正在动态集群中活动的部分节点，使新节点能够和这些节点进行交互并加入集群，从而完成重量级数据的多播。在本发明中，跟踪器主要职责由为新节点提供潜在合作节点转变成为集群现存节点均衡分配多播任务。在普通BT协议中，跟踪器会随机返回适量(一般为80)5节点给正在参与重量级数据多播的节点。在本发明中，釆用在整个节点中根据监测确定超级节点，让这些节点首先获得需要多播的轻量级数据。一般情况下，这些超级节点具备更多的并发连接，通过这些并发连接能够使轻量级数据以尽可能高的效率传输给其他相关节点。由此看出确定超级节点的重要性。超级节点的确定可以通过一个简单的方法实现，即在跟踪器上记录的节点活跃时间来衡量活跃时间长，则成为超级节点的可能性大；否则，就是普通节点。通常超级节点在动态集群中的活跃时间大大超过普通节点，因此容易根据这个数值识别超级节点。另外，即使超级节点识别有误差，也可以根据活跃时间找到一些相对可靠的节点；它们可以被称作次超级节点。之所以可以利用一些次超级节点，也是由于轻量级数据多播持续时间短、对该节点造成的负担小。根据上述原则选择的超级节点和次级超级节点会快速成为种子节点。之后，这些节点会通过当前并发连接传输轻量级数据。E.改变节点自私性为贡献性。在BT协议中，每个节点都被假设为以自私的方式工作,即在获得所需重量级数据后就会离开系统；同时在和其他节点交互过程中也只是在满足自身要求前提下才会和对方交互；否则，合作会中断导致退出系统或者寻找其他节点进行交互。这样的设计对于重量级数据多播是正确的。但是对于给系统压力小的轻量级数据来说就没有必要了。在轻量级多播系统中，为尽快完成多播任务，每个获得多播数据的节点应该主动通过自身具有的并发连接传输轻量级数据。无论是超级节点还是普通节点在轻量级数据多播时都以贡献性方式工作。通常普通节点拥有的并发连接个数要远远小于超级节点，这是与其带宽资源是匹配的，能够达到其所能承受最高压力。这样多播压力就均衡地分布在每个节点上，同时保证了多播的即时性。由于多播是在非稳定非规则拓扑结构中进行的，系统无需为维护拓扑结构付出代价，节点的动态特征对于多播质量的影响被降到最低。F.通过赋予轻量级数据以唯一标识避免轻量级数据冗余传输。由于本发明中的轻量级数据多播没有规则的拓扑结构，这容易造成数据的冗余传输，即一个节点收到多次重复数据。赋予轻量级数据以唯一标识，当一个节点收到数据时，会检査这个标识。如果出现重复，则停止传输给它的并发连接节点；否则，则传输给它的并发连接节点继续多播。G.通过轻量级数据经过的路径进行标识避免出现环路。同样由于本发明中的轻量级多播没有规则的拓扑结构，在数据传输过程中有可能形成环路，造成没有意义的数据传输。为此，可以在轻量级数据上标识出曾经经过的节点。当出现当前到达节点与轻量级数据经过的节点重复时，则停止传输；否则，继续多播过程。H.通过动态集群克服互联网的动态性。互联网环境由于人对计算节点的直接控制，导致系统动态特征明显。极端的动态特征会阻止任何计算的进行。实际上，在互联网环境中，用户导致的动态特征并不是没有规律的，而是由具体应用本身质量和性质所决定的。对于整个互联网环境来说，动态特征是绝对的；但对于一个具体应用或者具体应用的某一个时段，动态特征是相对的，甚至会表现出稳定特征。动态集群的建立为一个具体应用提供了动态互联网中相对稳定的计算环境。如果在这个环境中进行轻量级数据多播，通常来说会受动态的影响会减小到最低。I.保证轻量级数据在多播过程中的顺序。在有些应用中，轻量级数据的顺序是有意义的。任何一个节点必须按照此顺序进行响应才有正确的结果。至少对于事件驱动机制就是如此。对于轻量级多播来说，保证数据在传输过程中的顺序是事件驱动机制正确运行的基础。在高动态的互联网上，如需要对数据之间的顺序进行维护，跟踪器起到了协调作用。当一个节点上发送轻量级数据并进行多播时，首先要向跟踪器发出请求；跟踪器对集群内所有需要发送数据的节点按照跟踪器本地时间先后顺序进行排序；多播按照此先后顺序依14次进行，即当确认排在前面的节点数据在整个集群中发送成功后，排在其后的节点数据再进行发送。但这样的做法会导致整个系统由于过度同步而性能下降。也可以采取对被排序数据进行顺序编号，然后进行异步发送。每个节点对获得的数据进行处理时，如果发现编号不连续，则可以判断有数据没有收到，可以和数据源联系来获得相关数据。这个方法可以使得轻量级多播在高效率的前提下保证可靠性。第四步，建立互联网环境下的远程事件驱动机制。在上述工作的基础上，本发明提出了一个基于互联网环境的远程事件驱动机制。这个机制能够适应互联网动态变化的特征，保证事件驱动机制在高效稳定可靠大规模环境下工作。这个机制的实现提高了互联网计算节点之间的交互效率，避免了投票机制给系统增加的压力以及对系统变化迟钝反应。在投票机制中，一个重要参数就是投票周期。一般这个周期可以根据具体应用中事件性质以及事件关注者的需求来制定。当用户需要关注所有可能发生事件时，由于事件的发生决定于引发事件的源头，难以事先估计，所以投票周期的制定很难达到准确，从而造成投票周期与事件发生规律不一致。当投票周期大于事件发生频率时，关注者就会对事件的发生反应迟缓；当投票周期小于事件发生频率时，远程事件发生节点以及关注者节点就需要投入更多的资源进行投票，额外增加了系统的压力。事件驱动保证了关注者能够在事件发生前不用付出额外代价进行投票；同时，在事件发生后，能够即刻作出反应。由此可见，互联网环境下远程事件驱动机制成为了反映互联网变化的基础。互联网本质上是一个不断变化的系统，但这种变化在没有远程事件驱动机制的支持下，是无法即时反映到相关计算节点的。为了降低计算负担，当前互联网主要应用中甚至拒绝对这些变化予以跟踪。本发明有效地解决了这个问题。第五步，建立互联网环境下的远程事件驱动编程模型。在实现了互联网上远程事件驱动机制后，本发明结合软件工程技术，提出了基于互联网环境的远程事件驱动编程模型。这个模型对开发人员来说，表现为一套应用程序接口(API)。通过使用这些接口，用户可以在互联网上完成对各种可能事件的监控和响应。这套接口包括消息发送及相关事件、文件发送及相关事件、字节发送及相关事件和对象发送及相关事件。同时，也实现了这些接口对应异步接口7。这套应用程序接口包含了互联网计算中基本事件编程模型。在互联网应用中，与互联网计算相关的所有远程事件都以数据传输形式表现出来。因此，本发明中涉及的事件都与数据发送接口紧密关联。互联网计算对于数据的发送可以按照数据的性质分为四种类型，即消息、文件、字节和对象。这些类型都是独立于具体应用的基本事件。使用本模型时，开发人员需要根据本发明提供的应用程序接口发送数据，并利用提供的事件类型定义或者派生出与具体应用相关的事件。这其中对象发送及其相关事件提供了灵活的远程事件定义模式；开发人员可以根据自身需求定义各种基于对象传输的事件。实际开发中，只要继承这个抽象的对象，就可以派生出任意远程事件。表l列出了互联网远程事件驱动主要编程接口。表l.互联网远程事件驱动主要编程接口<table>tableseeoriginaldocumentpage16</column></row><table>本发明的积极效果为本发明在不增加网络成本的前提下，提高了网络计算资源，同时本发明编程模型内部的事件驱动机制，可以使网络用户能够及时自动的获取所关心的事件信息，使网络服务更加高效、便捷、人性化。图l.基于BT拓扑结构的轻量级数据多播；图2.本发明的方法流程图。具体实施例方式本发明的应用几乎可以覆盖所有互联网领域。在此，对一些主要应用中实施本发明的情况予以说明。利用本发明可以在下面多个应用中实施。第一，丰富互联网应用。所谓丰富互联网应用是为了解决传统互联网应用展示过于简单、与桌面应用差距明显的问题。互联网应用与桌面应用区别之一就是没有事件驱动机制。用户不得不通过不断刷新(向服务器请求)的办法从网站上获得更新的互联网数据。基于桌面的应用则不是这样。由于当前桌面操作系统都具备事件驱动机制，当用户关心的任何事件发生时，用户都可以在不进行任何操作的情况下获得事件通知，并进行相关反应。当前丰富互联网技术试图通过底层投票机制代替用户手动向服务器请求，给用户以事件机制的感觉。但由前面的讨论可以得到结论，与真正的事件驱动机制相比，投票机制并不是一个有效的解决方案。利用本发明的技术，可以妥善解决在互联网上实现事件驱动的问题。开发人员可以把任何远程事件通过本发明提供的编程模型描述出来，并把这个模型与具体互联网应用结合，形成针对具体应用的事件驱动机制。第二，电子邮件系统。电子邮件系统也是当前互联网主要应用之一。电子邮件的发送和收取本身就代表不同的事件。这些事件的发生是用户所关心的。一个基于远程事件驱动机制的电子邮件系统可以及时提示用户收到电子邮件或者发送电子邮件成功。当前互联网电子邮件系统没有远程事件驱动机制的支持，当用户收到电子邮件时，并不能得到及时通知。只有当用户主动访问邮件服务器时，才能得知当前邮件状态。一些电子邮件系统只能使用投票机制来完成这个工作。利用本发明的技术，可以把邮件发送与收取通过对象发送接口描述出来；无论是用户发送还是收到邮件都能够得到及时通知。第三，即时通信系统。即时通信是一种高频率的远程事件发生机制。当前互联网的即时通信机制没有事件驱动机制的支持，只能依赖投票机制形成模拟即时消息的获得。利用本发明，可以有效实现即时通信系统中发送消息和收到消息。实现这个目标时，本发明中的编程接口都可以利用，并且几乎不需要任何改动。第四，电子商务系统。电子商务系统中对远程事件驱动机制的需求很多。有些电子商务系统数据更新频繁，并且用户也关注这些更新，比如股票系统。股票系统中商业数据变动频繁，并且这些数据都是用户所密切关注的。当前只能依靠投票机制实现上述功能。利用本发明的技术，股票变更数据可以迅速有效获得。同时这里还存在多播的问题。通常股票变更数据有多个用户关注；简单的事件通知机制效率低，不能保证即时性。由于本发明拥有独特的多播技术，使得股票数据在众多用户中有效扩散。对于其他电子商务系统来说，也存在类似问题。这个问题集中体现在分布式事务管理3上。当有众多用户共同参与一个商业服务，会涉及对同一商业数据的改动。如果没有有效的事务管理机制，会造成商业数据的不一致，并最终引发混乱，造成商业损失。当有众多用户参与一个商业服务时，为了维持一致性，要求有效的事件通知机制以及多播机制。本发明的技术正好满足了这个需求。第五，网络游戏系统。网络游戏当中存在大量用户之间的交互以及用户和系统的交互。这些交互可以抽象成各种不同的事件。但是当前网络游戏系统也是沿用传统的投票机制进行事件驱动以及相关多播机制。这增加了系统负载降低了效率。利用本发明的技术，游戏用户之间和游戏用户和系统之间的事件都以最有效的方式进行。当有众多用户关心的事件发生时，本发明的多播技术也会起到有效支持作用。第六，新闻系统。新闻系统的显著特征就是数据变更频繁并且用户对变化敏感。然而由于新闻系统通常用户量大，为了避免对系统造成过大压力，这些系统甚至没有实现事件机制以及和事件机制紧密相关的有效多播机制。从这里可以看出，当前互联网技术的落后状态。利用本发明，新闻系统中的任何变更可以即刻被用户感知；同时，一个被大量用户感知的事件也可以通过多播方式即时通知相关用户。第七，公告栏系统。本质上，公告栏系统和一般以数据发布为特征的互联网应用性质是一致的。一些区别在于公告栏系统交互频率要比普通互联网发布系统要高。与普通互联网发布系统类似，公告栏系统也需要通过事件驱动机制以及相关的多播机制完成即时变更数据的通知和发送。基于与新闻系统同样的原因，当前公告栏系统也没有上述机制对系统进行辅助。在公告栏上的交互也需要事件驱动机制通知相关用户；这个功能在当前公告栏系统中也没有实现。利用本发明涉及的技术，上述问题都可以得到解决。第八，会议系统。互联网会议系统本质上是一个多个用户参与交互系统。会议当中有不同用户需要发布数据，这个数据的发布可通过事件的形式表现出来。使用本发明，会使得会议过程高效流畅，参与者可以即时感知会议数据的变化。同时，有些会议系统需要有重量级数据的支持。这个重量级数据的传输可以利用基于BT协议的流媒体传输机制6完成。这个机制构成的拓扑结构对本发明的多播机制会有辅助作用，使本发明依赖的轻量级多播表现出更高的质量。参考资料1AndrewD.Birrell，BruceJayNelson;ImplementingRemoteProcedureCalls;ACMTransactionsonComputerSystems(TOCS)，Volume2Issue1，1982JasonMassen，RobvanNieuwpoort,RonaldVddema，HenriE.Bal,AskePlaat;AnEfficientImplementationofJava'sRemoteMethodInvocation;PPoPP'99:ProceedingsoftheSeventhACMSIGPLANSymposiumonPrinciplesandPracticeofParallelProgramming,19993GeorgeCoulouris，JeanDollimore,TimKindberg;DistributedSystemsConceptsandDesign;PearsonEducation,Ltd;2004Obraczka，K.;MulticastTransportProtocols:aSurveyandTaxonomy,CommunicationMagazine,IEEE,Volume36，Issue1，Jan.1998Page(s):94-105CohenB.;IncentivesBuildRobustnessinBitTorrent，inWorkshoponEconomicsofPeer墨to-PeerSystems,BerkeleyUSA，May2006VlavianosAggelos,etal.BiToS:EnhancingBitTorrentforSupportingStreamingApplications,INFOCOM2006,25IEEEInternationalConferenceonComputerCommunicationsProceedings,April2006，Page(s):1-7MicrosoftAsynchronousProgrammmingOverview;http:〃msdn.microsoft.com/en-us/librarv/2e08f6vc(VS.71).aspx8NewmanMEJ.;TheStructureandFunctionofComplexNetworks,SIAMReview,2003，45,Page(s):167-259J.A.Pouwelse，et.al;TRIBLER:ASocial-BasedPeer墨to-PeerSystem;RecentAdvancesinPeer-to國PeerSystemsandSecurity,2006，Volume20，Issue2,Pages:127-13810M.Ripeanu;Peer墨to-PeerArchitectureCaseStudy:GnutellaNetwork;ProceedingsofFirstInternationalConferenceonPeer-to-PeerComputing,2001,Pages:99-10011PaulFrancis;IstheInternetGoingNUTSSIEEEInternetComputing,November/December2003,Pages:97-9912RosenbergJ.,etal;STUN—SimpleTraversalofUserDatagramProtocol(UDP)ThroughNetworkAddressTranslators(NATs);RFC3489，March20013NewmanMEJ.;TheStructureandFunctionofComplexNetworks;SIAMReview,2003，45,Page(s):167-256。权利要求1.一种基于互联网事件驱动机制编程模型的建立方法，其步骤为1)采用TCP/IP对等协议模式使计算节点具有接收请求和发送请求的能力；2)在计算节点之间建立直接对等的交互协议；3)在计算节点上建立基于消息的事件监听机制，用于接收数据；4)建立动态集群，并在动态集群内采用数据多播机制进行数据传输；所述动态集群为基于共同需求的计算节点在某一个时刻形成的计算资源协作共享模型；5)监测所述动态集群内的节点，将事件发生节点的数据通过所述数据多播机制传输给其它节点；6)结合软件工程技术，根据传输的数据类型建立事件驱动编程模型。2.如权利要求l所述的方法，其特征在于所述计算节点包括客户端和服务器端。3.如权利要求2所述的方法，其特征在于所述计算节点之间直接对等的交互协议的建立方法为1)建立网络连接监听机制；2)通过IPv6或NAT穿越技术实现互联网上任意节点的直接连接；3)根据具体互联网应用特征，建立不同的客户端和服务器端对等交互的协议。4.如权利要求l所述的方法，其特征在于利用异步编程模型结合TCP/IP协议完成所述建立基于消息的事件监听机制。5.如权利要求4所述的方法，其特征在于所述基于消息的事件监听机制的工作方法为在获得相关远程事件消息后，启动本地事件驱动机制把远程事件转换成本地事件，来驱动本地相关系统对远程事件予以响应。6.如权利要求5所述的方法，其特征在于所述相关远程事件包括消息远程事件、文件远程事件、字节远程事件和对象远程事件。7.如权利要求1所述的方法，其特征在于所述数据多播机制为利用BT协议形成的拓扑结构进行轻量级数据多播，其方法为1)采用BT协议的跟踪器监测动态集群中计算节点的状态，所述节点状态包括节点是否处于集群中、节点是否对某个事件关注、节点是否为超级节点、节点是否已获得某个事件；2)对于处于集群中节点，所述跟踪器均衡分配多播任务，其方法为首先为传输数据设置唯一标识；然后所述跟踪器将确定出的超级节点作为种子节点，通过并发连接向其它节点传输数据；节点检查接收到的数据的标识，如果出现重复，则停止传输给该节点的并发连接节点；否则传输给该节点的并发连接节点继续多播。8.如权利要求7所述的方法，其特征在于所述传输数据上标识有曾经经过的节点，当出现当前到达节点与轻量级数据经过的节点重复时，则停止传输；否则，继续多播过程。9.如权利要求1所述的方法，其特征在于所述数据类型包括消息、文件、字节和对象。10.如权利要求9所述的方法，其特征在于所述事件驱动编程模型包括消息发送及相关事件、文件发送及相关事件、字节发送及相关事件和对象发送及相关事件。全文摘要本发明公开了一种基于互联网事件驱动机制编程模型的建立方法，属于互联网应用开发领域。本发明首先使计算节点具有接收请求和发送请求的能力，然后在计算节点之间建立直接对等的交互协议以及在计算节点上建立基于消息的事件监听机制，之后在具有共同需求的节点间建立动态集群并在动态集群内采用数据多播机制进行数据传输；监测动态集群内的节点，将事件发生节点的数据通过数据多播机制传输给其它节点；最后结合软件工程技术，根据传输的数据类型建立事件驱动编程模型。本发明在不增加网络成本的前提下，提高了网络计算资源，同时编程模型内部的事件驱动机制，可以使网络用户及时自动的获取所关心的事件信息，使网络服务更加高效、便捷、人性化。文档编号H04L29/08GK101645912SQ20081011782公开日2010年2月10日申请日期2008年8月5日优先权日2008年8月5日发明者冰李申请人:北京大学