CN1653750A - 用于在通信网络中组织管理器对象和被管对象之间的通信的方法，体系结构及其软件 - Google Patents

Abstract

一种用于通过通信网络(R)用至少一个管理器对象管理至少一个被管对象(B1，...，BN)的方法，包括以下操作：提供至少一个中间对象或分级代理(AG)，其配置为根据一个数据集(1100)管理所述至少一个被管对象(B1，...，BN)，所述管理被转换成结果集(1104)，从所述至少一个管理器对象(A)提供所述数据集(1100)给所述中间对象(AG)，通过所述至少一个中间对象(AG)管理所述至少一个被管对象(B1，...，BN)，以产生所述结果集(1104)，以及从所述至少一个中间对象(AG)发送(1108)所述结果集(1104)到所述至少一个管理器对象(A)。优选地，管理器对象(A)和中间对象(AG)之间的通信实现UDP协议和压缩模式。

Description

用于在通信网络中组织管理器对象和被管对象 之间的通信的方法，体系结构及其软件

技术领域

本发明涉及用于在电信网络的环境中建立至少一个管理器对象(下文简称“管理器”)和至少一个被管对象(下文简称“代理”)之间的通信的方法。

背景技术

一个用于此目的的典型的参考体系结构如图1所示，说明通过电信网络R互连的一个管理器模块A和一定数量的代理元素B1，B2，B3，...之间的连接。

此体系结构，例如，在SNMP(简单网络管理协议)规范中描述。可参考文档RFC 1157，1990修正版。

一般而言，因特网协议体系结构采用4个逻辑层，通常称为应用(A)，传输(T)，网络(N)和链路(L)。

如图2所示，每一层实际是嵌套在下层协议中。例如，应用层协议，诸如前文提及的SNMP和TFTP，即Telnet或FTP协议，都嵌套于下层协议中。

特别地，SNMP和TFTP协议嵌套于UDP(用户数据报协议)中，UDP协议又嵌套于IP协议(网际协议)中，并因此通过软件驱动程序或硬件设备注入到参考标号D所表示的物理载体(电缆，光纤，无线电波)，从而实现物理层上的链路L。

同样，Telnet和FTP协议嵌套于TCP(传输控制协议)中，TCP协议又嵌套于IP协议中，并因此注入物理载体设备L。

传输层的TCP和UDP的主要特征在以下条款中描述。

TCP是面向系统通信的协议(系统由网络地址确定)，并与其使用的软件链接。用此协议建立通信前，必须建立一个连接，即，与远程系统的永久通信。数据传输是受控并有保证的，但是很缓慢，尤其在数据不连续或很小时。IP协议的特征，以及在每个请求之后创建连接，并在通信结束如果不使用就删除，即关闭的事实，导致了时延。由于协议的复杂性，和为确保通信的正确性而对数据和连接的检查的复杂性，就所使用的系统资源而言，通信是昂贵的。

反之，UDP协议是面向进程通信，进程通信由每一个以在0到65535范围内的数字为特征的逻辑端口确定。对于传输，协议接收来自不同应用程序的消息，并将其传送给IP协议以传输。此功能称为多路复用。对于接收，UDP协议通过目的应用进程接收来自IP层的数据包。此功能称为去多路复用。

UDP协议占用资源较少，并易于实现和管理。特别地，它使用一个简短的64位的首部(称为“PDU用户首部”)分为“源端口”，“目的端口”，“长度”和“校验和”以及一个92位的包括“源地址”，“目的地址”，“填充位”“协议类型”，“PDU长度”字段的首部。

UDP协议速度较快，因为IP传输协议不要求处理或检验；其仅仅在可能的情况下从当前网络地址传输到目的网络地址。

UDP协议本身不使用接收确认消息，不对消息分类，不检查流，因此不是完全安全或可靠，因为消息可能丢失，丢弃，复制，错序接收，或到达速率可能高于网络中的应用和接收进程的速率。

使用UDP作为传输协议的一般处理体系结构的特征为，根据图3中所示的标准与一个端口关联。

使用两个基本标准来分配接收和发送端口的号码。

第一个标准在于确定通用的分配，其中各个端口号由官方确定并为所有方认可。

第二个标准在于确定动态绑定，程序在需要时根据动态绑定请求一个端口，该端口由网络软件分配。接收端口通常预先分配，即使其可能被修改。发送端口可使用两种方法中的任一种确定。

特别地，图3所示，参考标号PA通常表示不同的应用进程(1，2，3...)，其通过3个各自的端口与UDP协议交互。

可以确定称为“物理对象”和“逻辑对象”的附加集成组件，以及基于UDP协议的管理体系结构中的应用进程，如图4详述。

根据当时所起的作用，应用进程又可分成具有管理器功能的始发者应用进程，通常用参考标号A表示，和一个(或多个)目的应用进程(称为代理)。

术语“物理对象”用于，拥有应用操作所需的其他物理对象的硬件容器或媒介(例如，个人计算机)。图4中，容器用参考标号P₁，P₂表示。另外的物理对象包括物理的(例如，RAM)和/或虚拟的(例如，文件)处理存储器，以及硬件媒介所使用的用于运行进程(软件，基本固件，协议，应用)的中央处理单元(CPU)。图4中，此类存储器用参考标号R₁，R₂标识。

图4所示，参考标号W表示操作系统级的系统软件，参考标号Y和Z表示包括一个或多个面向应用软件的协议(传输)和面向网卡或CR换能器的软件(此种情况包括一个或多个协议)，用于与网络R交互。

以下描述涉及图4，其表明了应用进程，对象和体系结构组件之间的关系。系统软件W用于执行使用处理存储器R₁，R₂的可用部分的系统或设备中所分配的任务。

系统P₁中的进程A与系统P₂中的进程B，通过双方设备中必需的组件W，Y和Z，网卡和物理媒介进行交互。

软件组件A，B，Y，Z和W根据其特征，使用和共享一定数量的存储器R₁，R₂。

最大可用带宽与必须一致的网络R和网卡CR的特性相关。

使用图1所示类型的体系结构的可能性以一些因素为条件。

首先，网络R的最大可用带宽以管理器和代理的数量及产生的流量为条件。可用带宽只有在仅有两个设备，即一个管理器和一个代理时最大。如果有一个管理器和几个代理，可用带宽必须被共享。因此，不能保证管理器和代理之间每个通信的最大可用带宽。

通常，用顺序策略或并行策略可管理一个管理器和几个代理之间的通信。

在顺序策略中，管理器建立与代理之间的通信，并在继续下一个通信之前等待此通信的结束。

并行策略采用协议(典型地是UDP，用户数据报协议)提供的多路复用和去多路复用功能，通过竞争的动态端口分配机制，建立一定数量的与几个代理的同时通信。

根据顺序方法，管理器到代理的输出带宽(即，全部被发送消息大小的总和除以发送所用的时间)和管理器输入带宽(即，每一个节点管理器所接收的全部消息大小的总和除以管理器接收所需的时间，接收时间是代理处理时间和网络时延的总和)很小，因为发送和接收时间很长。

根据并行方法，管理器到代理的输出带宽很大，输入带宽也可能很大，因为发送和接收时间很短，而且响应确实大于所要求的。

图1所示的根据已知技术的体系结构呈现很多局限和缺点。

当代理的数量超过一定值(例如，1000)时，顺序发送无效。这是由于完成活动所需时间大大增加。而且，由于管理器的同时请求所产生的流量和代理所产生的返回流量可能同时出现，图1的体系结构产生大规模的流量突发。这可能超过可用带宽限制，并因此降低网络功能，导致消息丢失。

并行方法使用几个分配到不同UDP端口的管理器进程，这将耗尽诸如RAM和CPU的所有系统资源。

对于传输大量信息或工作于有大量协议的网络，应用进程所使用的协议，例如上述SNMP协议或TFTP简单文件传输协议(见文档RFC1350)，并不是最优化的。此外，协议是点对点型的，因此不能实现和管理多级体系结构。

而且，图1所示体系结构，所有代理应能被管理器以某种方式直接访问。不能被管理器直接访问的代理，例如由于连接到与管理器不同的网络，要求安装专用管理器进行管理。

发明内容

本发明的目的是提供一个能克服上述缺点的解决方案。

根据本发明，此目的可通过一个方法实现，其特征在所附权利要求书中具体陈述。本发明也涉及相应的网络体系结构和相应的软件，即，可以被直接上传到数据处理单元的存储器的软件，该数据处理单元包括当软件被至少一个数据处理单元运行时，能实现根据本发明的方法的软件代码部分。

基本上，根据本发明的解决方案实现了优化的多级管理体系结构，从而将管理活动细分到几个机器，借此克服关于使用传统的单级体系结构需求的局限。所有这些限制了带宽的使用，特别涉及优化利用物理管理器资源的可能性。

简言之，根据本发明的解决方案，在于实现一个中间对象，即一个称为“分级代理”新型的代理，其能接收来自管理器的足够信息从而执行管理器直接在受控代理上执行的管理活动。

因此，如后详述，在与压缩UDP消息传输方法联合使用时，根据本发明的解决方案是适当而且尤其有利的。

附图说明

在此，参照附图仅通过举例描述本发明，其中：

图1至图4，涉及已知技术并已在上文陈述，

图5以一般术语说明根据本发明的新的管理体系结构，

图6说明根据本发明的解决方案的实施方式的第一种形式，

图7说明根据本发明的解决方案的实施方式的第二种形式，

图8说明根据本发明的体系结构的一个操作逻辑实例，

图9说明在根据本发明的体系结构内的一个可能的通信管理图，

图10说明共享代理管理方法，

图11说明根据本发明的所谓的分级代理的体系结构，

图12说明在本发明的范围内由分级代理支持的一个可能的结构组织和控制嵌套，

图13至图15，每个图分成涉及发送(a部分)和接收(b部分)的两个部分，以流程图形式说明根据本发明的解决方案的实施方式的某些优选形式，

图16是说明根据本发明的解决方案的更普遍的特征的附加流程图，以及

图17和图18说明根据本发明的两个可能变体的解决方案的附加的可能实施方式。

具体实施方式

图5所示，说明根据本发明的一般体系结构。

直接与图1比较，一个附加模块，即一个称为分级代理AG的中间对象，被集成到根据本发明的体系结构中，此体系结构基于一个管理器A和多个互相通信的代理B1，B2，B3的存在。

基本上，分级代理AG与管理器A通信以从管理器接收足够数量的信息，从而在一定数量的代理B1，B2，B3(可能是任意数量的代理)上执行与管理器A同样的管理活动。

在根据本发明的解决方案中，管理器A继续维护和直接控制其他代理，图5中用参考标号BK，...，BN表示。

显然，可实现代理B1，...BN的数量的任意数量，以及用于分级代理AG和管理器A之间管理目的的任意数量的划分。

图5所示体系结构用于创建多级体系结构，而无需复制管理器功能，因为新的元素(即分级代理AG)可用于进行必要的活动并取得理想的结果。

实际上，称为分级代理AG的中间对象能以代理(B1，B2，B3，...)的形式，从管理器接收适当定制的消息，例如包含足够信息的SNMP消息，从而执行管理器A所要求的使用特定协议(SNMP，TFTP，Telnet，DNS，等)，在通过网络地址确定的特定的代理上的活动。在所要求的活动之后，AG模块将结果发送到管理器A。管理器A和分级代理AG之间的互连的实现可使用网络R(图6所示实施方式的形式)或使用通过双连接的不同的网络(图7所示实施方式的形式，其中参考标号RP和RA表示这两个网络)。

图7说明根据本发明的解决方案的极其灵活性。

特别地，该图说明，参考标号RP所表示的第一个网络可用于管理器A和继续由A直接管理的代理B1之间的通信，以及用于允许管理器A和分级代理AG之间的通信，AG在参考标号RA表示的第二个网络中“取代”管理器A，对代理B2和B3进行管理。

根据本发明的解决方案也在带宽方面优化了网络(通常是多个网络)的使用。

特别地，算法压缩优选地应用于应用协议所包含的数据(SNMP中的OID，UDP中的有效载荷，等)，从而减少由于管理器A和分级代理AG之间通信所引发的网络流量。

此方法基本在于(至少)对消息有效载荷执行压缩操作，优选地基于消息中周期性出现的序列确认。以特定的优选方式，根据诸如zlib的gzip方法执行此压缩操作。

参照图12和下文详述，此方法减少了交换的PDU数据包，有利于更高的数据内容。

例如，TFTP协议中的一个数据PDU使用516字节，因此，传送一个520Kb的文件需要1016个包。根据上述标准进行压缩，520Kb缩减为4Kb，这意味着它们可以在一个UDP数据包或SNMP消息中传送。因此传送在于传输“等价的应用消息”而不是“一条消息”。这意味着，所产生的流量可以减少，而所传输的数据是相等的。

所述解决方案也可用于优化执行活动所需的系统资源。

这是由于所述解决方案将管理器的活动分布到几个分级代理AG，例如根据图10所示的标准。图中，参考标号AG1和AG2表示两个分级代理，其与管理器A协作管理一定数量的代理B1至B5，对一个或多个代理(本例中为代理B3)的管理可由两个分级代理AG1和AG2分担。

在几个分级代理上分担管理器A的活动的可能性可被用于使用当时闲置的资源(CPU，RAM，等)。专有地由分级代理AG1和AG2返回到管理器A的流量——仅在活动结束时产生，在于由分级代理AG1和AG2传送到管理器A的结果。优选地根据压缩方法，从而通过使用大小为中到小型，数据内容很高的包，产生流量。这些包不影响管理器A解压和管理所需的系统资源。

以此方式，如图8所示，管理器A和分级代理AG之间的交互(为了简明，以及扩展到几个分级代理模块将会明白易懂，下文中此类型的单个模块都有参考标号)是基于微活动的执行和对管理有用的信号的交换。

特别地，在参考标号1100所示步骤中，管理器A以消息的形式，例如通过使用标准或压缩的SNMP消息，向分级代理AG发送活动请求。在参考标号1102所示步骤中，分级代理AG接收并分析请求，开始处理和收集信息。在处理过程中——步骤1104——分级代理AG向管理器发送统计消息以及处理中用于同步活动状态的消息：其发生在参考标号1106所示步骤中。结束了对被管对象，即代理，的管理活动后，分级代理AG向管理器A发送结果。其发生在参考标号1108所示步骤中。在参考标号1110所示步骤中，管理器A通过在步骤1112中向分级代理发送结果接收确认消息，接收并处理活动结果。然后，分级代理AG在参考标号1114所示步骤中结束所请求的活动。

根据所取得的结果，此循环可能由管理器重复几次。例如，如果认为某些数据不充分，可发送新的请求。

图9描述的是，分级代理AG的高级逻辑元素及其与体系结构的其他组件的关系。

应注意，图9基本与图5的体系结构相符，其中，管理器A直接管理某些代理BK，...，BN，并将对其他代理B1，B2和B3的管理授权给分级代理AG。网络R的交互如图6所示。

通过执行UDP协议的通信，例如使用标准或(优选地)压缩的SNMP消息，管理器A与其直接代理以及分级代理AG进行交互。

为此目的，以及控制和管理逻辑LCG，分级代理包括用于管理分级代理AG和管理器A之间通信的两个模块(分别由参考标号ARX和ATX表示)，这样，分级代理AG基本可被管理器A“看作”是另一个由管理器A直接管理的代理。

此外，分级代理AG包括一个多管理器模块MM，其监控分级代理AG和代理B1，B2，B3之间的通信，这样，每个代理可基本将分级代理AG“看作”是管理器A。

管理器A和分级代理AG的多管理器组件与不同的代理使用标准方法/协议通信。

因此，如图10所示，一个代理(示例中为代理B3)可以被同一个管理器控制的一个或多个分级代理AG1或AG2管理。

图11说明实现结果管理和控制逻辑的分级代理AG的内部体系结构。

以优选方式，根据本发明的解决方案是基于完全消息压缩(参考标号MH所示的首部和PDU)。

特别地，可以使用两种可能的不同传输方法或实施方式。

第一种方法将SNMP消息嵌套在一个新的压缩SNMP消息中，并使用标准UDP发送。

第二种方法直接通过驱动程序控制UDP，提供压缩为数据字节的SNMP消息的结果。

压缩方法基本基于周期性出现在消息中的序列确认。

在实施方式的一个特别优选形式中，LZ77方法的一个变体被用作压缩方法(见Ziv.J.，Lempel A.，“顺序数据压缩的一个通用算法”，IEEE信息论学报，Vol.23，No.3，p.337-343)；此方法在UNIX环境下众所周知。其被称为gzip(gzip格式——RFC1952)，也被流行的PKZIP应用所使用。此方法的规范属于公共领域。源码库是可用的，从而可以在不同的开发环境和操作系统，例如，HP-UX，Digital，BeOS，Linux，OS/2，Java，Win32，WinCE，实现和使用此类解决方案。

特别地，使用“zLib”库可将算法移植用于Win32。该库的主要特征是允许对作为系统性能的基本要素的二进制数据结构和字符串在运行时和内存压缩。

图11说明上述参照图9的ARX和ATX模块。

ARX模块专门负责从网络R收集消息，并将其传送到参考标号G所示的队列管理模块中的输入队列I。

相应地，ATX模块专门负责发送来自参考标号U所示的队列管理器G的输出队列的消息。

队列管理器或模块G专门负责在每一个时钟脉冲分析来自输入队列I，输出队列U以及参考标号L所示的另一个队列(称为工作队列)的消息。

该时钟信号由参考标号T所示的定时器模块或定时器产生，其专门负责产生队列管理器G的同步时钟。

输入队列I中的消息被获取并发送到DC模块，该模块是消息的解释模块(和解压模块，在优选实施方式中)，用于将来在每一个定时器T产生的时钟信号进行处理。该解压/解释模块由参考标号DC所示。

而且，在每一个定时器T产生的时钟信号分析工作队列L中的消息；对于队列中的每一条消息，在输出队列U中产生一条表示活动状态的消息。

在每一个定时器T产生的时钟信号，输出队列U中的消息通过ATX模块被发送到管理器。

更详细的，DC模块专门负责分析输入队列I接收的每条消息，根据需要将其解压，并根据优先级将其发送到活动协调模块CA，指明已处理活动活动的方法和类型。

CA模块基本负责：

——通过参考标号CM所示的管理器控制模块的协调活动，实例化一个适于消息解释器请求的并行处理，并监控状态；

——更新工作队列L中的请求的活动状态，以及

——创建通过输出队列U发送到管理器A的统计检查消息，此消息包括关于示例的并行处理的全部操作状态的统计信息。

通过收集和分析所接收的信息，CM模块以协作和独立的方式管理可能的其他协议管理器模块(在此以示例的方式说明其中三个，如参考标号MP1，MP2，MP3所示)。活动结束时，鉴于其后插入到输出队列U以发送到管理器A，结果被发送到参考标号CCM所示的消息编辑和压缩模块，。

CCM模块专门负责管理并行处理所产生的活动的结果，创建消息，如果请求是压缩的，可将该消息压缩，并将其置于队列管理器输出队列。

每一个被称为协议管理器的模块MP1，MP2，MP3(在此，根据所管理的协议的数量，可以是任意数量的管理器)负责通过各个具体的协议(例如，Telnet，SNMP，TFTP，等)与代理通信。

系统中，为每条消息分配单一意义的标识号，以便在体系结构中快速，无误地识别。分级代理AG代理体系结构的特征可概述如下。

由于用简单组件模拟网络协议(例如SNMP，Telnet，DNS，TFTP，等)，分级代理AG配置为相对传统的管理器较为轻载的模块。例如，在TFTP协议中，仅实现同与协议兼容的代理通信的基本单元而不是整个服务器。

分级代理AG也比传统的管理器快，因为其仅使用和优化主机系统的RAM，不访问例如磁盘或数据库，而其是出名地缓慢。此外，分级代理AG不包括复杂管理器类型消息处理功能，在资源使用方面，仅在收到来自管理器A的请求时被激活，而在活动结束时失活，因此比传统的管理器更有效。

所述体系结构用于实现包括几个协议类型的几个同时，协作的活动，提供以分级模式访问代理的可能性，即允许某个代理被两个分级代理访问，第一个分级代理作为初级元素，第二个分级代理作为管理器A的二级元素。

这意味着，当第一个分级代理不可用时，可以使用二级分级代理。

因此，在出现错误或，通常(也是暂时)某些元素不可用时，所述解决方案更健壮。

对于分离的双向通信，ARX和ATX模块的可用性意味着，可以管理高容量的输入流量而不危害传输性能。尤其，ATX模块传输是使用称为“分时”或“高斯”的方法管理，此方法根据消息块各自的优先级进行消息传输。此方法根据优先级，在每一个时钟信号发送预定数量的消息，因此避免了可能的流量突发(例如，20条优先级为“1”的消息，10条优先级为“2”的消息，8条优先级为“3”的消息，2条优先级为“4”的消息和1条优先级为“5”的消息)，而剩下的消息排队并在下一个周期发送。此外，这避免了“瓶颈”的形成，因为每条消息通过内部缓存从一个模块流向另一个模块，内部缓存分散了模块处理速度。

在一个特别优选实施方式中，用于管理器A和分级代理AG之间的通信的消息结构，根据图12所示方法，表示为首部I及其后的数据体CI。

在此具体实例中，首部I典型地包括以下信息：

——消息格式版本(例如1.0)，

——最大命令处理时间(毫秒级)，

——压缩内容标识位(1＝编码，0＝未编码)，

——错误描述(在消息中编辑，确认无误或包括错误文本)，

——消息大小(字节)，

——执行活动的代理的IP地址，

——管理器所表示的消息的优先级(0＝由分级代理AG分配的优先级，1＝最大，5＝最小)，

——所使用的协议管理器的确认，

——所要求的活动类型(命令自身)，

——管理器请求的源UDP端口，

——管理器A或分级代理AG的版本，

——管理器内请求的单一意义的确认。

数据体CI包含用于执行所请求活动的协议管理器(MP1，MP2，MP3，...)的具体信息。这些标识根据所执行的活动和所使用的协议而有所不同。例如，可陈述以下内容：

——SNMP程序：包括一个具有被请求的OID SNMP，所执行的操作的类型(GET，GET NEXT，SET和BULK，等)的标准的SNMP消息，

——Telnet程序：包括认证参数(UID，密码)，操作者命令，是否返回命令所产生的输出的标示，

——SNMP程序：包括通过标准SNMP操作类型(BULK或GETNEXT)搜集的所有MIB分支的OID SNMP，

——协作程序：包括脚本方式的多协议协作方法，

——TFTP文件管理程序(非标准)：包括活动类型(上传或下载)，所搜集或下载的文件的列表，

——代理可访问性测试程序：包括通过DNS查找和反向DNS查找，ping执行的测试类型，Telnet和SNMP端口的可访问性，

——分级代理可访问性测试程序：不包括被执行的活动吗？被管理器A使用以测试分级代理AG的可访问性吗？以及

——统计传输命令：包括注册和确定管理器A的UDP端口的数据，统计数据被发送到该端口。

反之，使用包括压缩操作的算法压缩方法，命令也可被压缩和嵌套，特别地基于周期性出现在消息中的序列确认。

特别地，如图12所示，消息的首部I和数据体CI可以嵌套在一个分级代理AG支持的消息结构中，其包括消息首部MH和产生易于在IP层传输的SNMP或UDP消息的其余部分PDU。

图13的流程图说明用于压缩(图13a)和解压(图13b)SNMP消息的方法。

图14的流程图说明(再次，图14a是关于发送，图14b是关于接收)第一种解决方案，其中压缩的SNMP消息通过SNMP嵌套传输。

图15的流程图涉及一个通过UDP嵌套的传输解决方案。再次单独编号，发送(图15a)和接收(图15b)。

图17和图18分别涉及图13和14的a)部分(图17)以及图13和图15的a)部分(图18)示例的全部压缩和传输操作。

在图13的流程图中，参考标号100表示整个SNMP消息(首部+PDU)被读取和转换的步骤，在随后的参考标号102表示的步骤中转换成十六进制格式。这通过应用BER类型编码实现。

以此方式编码的消息使用基于周期序列的确认的压缩方法进行在内存压缩，如上文提到的zLib库中所述的方法。

这在参考标号104表示的步骤中进行，从而获取准备在步骤106中传输的压缩数据单元。

对称地，图13b部分的流程图包括4个步骤206，204，202和200(以将此顺序进行处理)，鉴于随后的十六进制解码(步骤202)，和随后的内部的SNMP消息的重组(步骤200)，接收的压缩数据单元(步骤206)被解压缩(步骤204)。

图13b)部分的流程图中，步骤的数字参考标号与处理的顺序相反，仅为了强调与步骤100到106的压缩过程的对称。关于图14和图15中的流程图做同样选择。

如图示，图14和图17涉及传输解决方案，其中压缩数据单元被嵌套在标准SNMP消息中，其特征为变量绑定和标准UDP传输方法。

步骤106中的压缩数据单元嵌套方法包括一个初始步骤(参考标号108所表示)，其中，按字节读取压缩数据单元，然后将其转换到相应的ASCII字符集(在随后的参考标号110所表示的编码步骤中)。

消息的变量绑定包括第一个编号的包含_ZIP_XXXX字符串的值(其中XXXX是原始文件的大小)的OID(例如1.3.6.1.4.666.1)，并在随后的参考标号112表示的步骤中产生(可能在诸如ACKTAB+NULL的辅助功能之后——见图17的方框110a)。上例中使用目前未被IANA互联网网络号分配机构注册的所有者代码666.1。

随后的包含转换为ASCII的压缩数据单元的变量绑定元素包含OID/值对。该值包括转换成ASCII格式的最大为255个字符的压缩数据单元部分。

然后，SNMP消息的首部数据被重组。这在步骤112中执行，其后是步骤114，执行根据BER方法的附加编码方法，从而产生PDUUDP有效载荷用以发送数据(步骤116)。

而且在此，图14b)部分中参考标号216，214，212，210和208所表示的步骤，将以上述顺序被执行，它们是在涉及发送的从108到116的接收步骤中执行的对偶功能。

通过采用图14和图17说明的解决方案，压缩SNMP消息有一个标准SNMP逻辑格式和所有者内容。因此，要求功能扩展(最小)以允许确认和编码/解码。

申请人所做实验证明此解决方案完全可行，而对网络体系结构没有负面影响。

可选解决方案(参照图15和18)在于根据图13所述方法准备从SNMP消息开始的压缩数据单元，其后将该数据单元直接嵌套在PDUUDP有效载荷中。

当然，为保证正确的操作，此解决方案要求专用发送器和接受器(例如，图9和11中的ARX和ATX模块)的可用性，例如，要求不同的而不是标准的UDP端口的可用性的情况。因此，发送器必须知道接受器所使用的UDP端口，反之亦然。根据以下详述的标准，所用端口上的信息可在较高层通过标准SNMP格式的同步消息进行交换。

通过采用图15和图18所述的可选方案，压缩数据单元在步骤108中成为可用，并将取代消息中的BER成为UDP消息的有效载荷。

各个操作在图15和图18中的参考标号数字120表示的步骤中概述。此步骤超前发送步骤122，其目标为接收器的各自专用的端口(通常称为端口X)。

而且在此，补充操作包括3个步骤，由参考标号222(通过此时接收模块的端口Y接收)，220(PDU UDP有效载荷提取)和218(创建将被发送到图13b部分的流程图的步骤206的压缩数据单元)表示。

而且在此，步骤222，220，和218以此顺序被执行。

根据通用的应用之间的标准，以上描述中参考的同步消息被管理器A发送到分级代理AG，使用包含所有者变量绑定的标准SNMP格式。

所传送的数据类型是：OID                       Value

1.3.6.1.4.666.2	<UDP_TX_Port>
		1.3.6.1.4.666.3	<UDP_RX_Port>

管理器A向分级代理AG发送所有者消息编辑包含用于UDP发送的端口号(例如1024)的<UDP_TX_Port>和包含用于UDP接收的端口号(例如1224)的<UDP_RX_Port>。分级代理AG通过发送包含自身信息的类似消息响应管理器A。此方法通过提高解决效率减少了处理时间。

此外，图16的流程图说明所述解决方案如何推广并应用到任何类型的使用UDP传输的消息(例如，SNMP，PING，等)。这些推广可用于产生能替代目前使用的UDP驱动程序。

此解决方案在于估计将传送的有效载荷的大小，如果大小合适(例如大于20字节)，继续所述方法。UDP消息首部从62位到69位的8位可用于规定UDP消息的压缩特性，例如通过设置其中一位为1(此位目前未使用，缺省设置为0)。

特别地，图16中参考标号300表示任何产生发送在UDP消息中易于转换的消息的需要的步骤，其后是根据上述方法压缩有效载荷的步骤302。

随后的步骤304在于根据上述条款产生UDP消息首部。参考标号306表示的随后步骤相应于创建完整的UDP消息准备IP传输(步骤308中执行)。

当然，在此设想，在不偏离以下权利要求书所确定的本发明的范围时，对于本发明的结构和实施方式可以实行很多改变。

Claims (30)

1.用于实现由至少一个管理器对象通过通信网络(R)对至少一个被管对象(B1，...，BN)的管理活动的方法，其特征在于，包括以下步骤：

提供被配置用于根据一个数据集(1102)管理所述至少一个被管对象(B1，...，BN)的至少一个中间对象(AG)，所述管理活动被转换为一个结果集(1112)，

从所述至少一个管理器对象(A)为所述中间对象(AG)提供所述数据集(1100)，

通过所述至少一个中间对象(AG)管理所述至少一个被管对象(B1，...，BN)，以产生所述结果集，

将所述结果集从所述至少一个中间对象(AG)传送(1108)到所述至少一个管理器对象(A)。

2.根据权利要求1所述的方法，其特征在于包括，通过UDP协议在所述至少一个管理器对象(A)和所述至少一个中间对象之间建立通信的步骤。

3.根据权利要求1或2所述的方法，其特征在于，包括以下步骤：

直接通过所述至少一个管理器对象(A)管理至少一个另外的被管对象(BK，...，BN)，以及

通过所述至少一个管理器对象(A)经由所述中间对象(AG)管理所述至少一个被管对象(B1，B2，B3)。

4.根据权利要求3所述的方法，其特征在于包括，通过单一的通信网络(R)管理所述至少一个另外的被管对象(BK，...，BN)和所述至少一个被管对象(B1，B2，B3)。

5.根据权利要求3所述的方法，其特征在于，包括以下步骤：

提供第一通信网络(RP)，用于直接通过所述至少一个管理器对象(A)管理所述至少一个另外的被管对象(B1)，以及在所述至少一个管理器对象(A)和所述至少一个另外的被管对象(B1)之间传送所述数据集(1100)和所述结果集(1108)，和

提供第二通信网络(RA)，用于通过所述中间对象(AG)管理所述至少一个被管对象(B2，B3)。

6.根据前述任何一项权利要求的方法，其特征在于包括，提供多个所述中间对象(AG1，AG2)和通过所述多个中间对象中的几个中间对象(AG1，AG2)管理至少一个被管对象(B3)的步骤。

7.根据前述任何一项权利要求的方法，其特征在于，所述中间对象(AG)装备各自的接收模块(ARX)和发送模块(ATX)，这些模块的配置使得所述至少一个管理器对象(A)将所述中间对象(AG)基本上看作是所述被管对象(B1，...，BN)之一。

8.根据前述任何一项权利要求的方法，其特征在于，所述至少一个中间对象(AG)包括至少一个各自的管理模块(MM)，该模块的配置使得由所述至少一个中间对象(AG)管理的所述至少一个被管对象(B1，...，BN)，将所述至少一个中间对象(AG)基本上看作是所述至少一个管理器对象(A)。

9.根据前述任何一项权利要求的方法，其特征在于，所述至少一个中间对象(AG)被提供了以下队列之一：

输入队列(I)，用于收集关于所述至少一个中间对象(AG)的输入消息，

输出队列(U)，用于收集来自所述至少一个中间对象(AG)的输出消息，以及

工作队列(L)，用于收集由所述至少一个中间对象(AG)在所述至少一个被管对象(B1，...，BN)上执行的所述管理活动所固有的消息。

10.根据权利要求9所述的方法，其特征在于包括，在所述至少一个中间对象(AG)中提供一个专用模块(DC)，用于分析所述输入队列(I)所接收的输入消息的步骤。

11.根据权利要求9或10所述的方法，其特征在于，包括以下步骤：

在所述至少一个中间对象(AG)中提供一个活动协作模块(CA)，用于实现至少一项以下功能：

实例化(instantiate)至少一个并行处理，

更新所述工作队列(L)中的请求的活动状态，以及

创建将通过所述输出队列(U)发送到所述至少一个管理器对象(A)的统计检查消息。

12.根据前述任何一项权利要求的方法，其特征在于包括，提供多个协议管理模块(MP1，MP2，MP3)的步骤，这些协议管理模块被配置为，通过在所述至少一个中间对象(AG)中的各自不同的协议，建立到所述至少一个被管对象(B1，...，BN)的通信。

13.根据前述任何一项权利要求的方法，其特征在于包括，通过将所述各自消息的至少一个部分经过压缩操作(302；104，204)，在所述至少一个管理器对象(A)和所述至少一个中间对象(AG)之间建立通信的步骤。

14.根据权利要求13所述的方法，其特征在于，所述压缩操作是基于对周期性出现在该消息中的序列的确认。

15.根据权利要求14所述的方法，其特征在于，所述压缩操作实现一个诸如zLib的gzip型方法。

16.根据权利要求2和13-15中任何一项所述的方法，其特征在于包括，指示由UDP所传送的消息的压缩已经执行的步骤。

17.根据权利要求16所述的方法，其特征在于，UDP首部中的位字段用于指示压缩操作(302)已经执行。

18.根据权利要求17所述的方法，其特征在于，包含在UDP首部的从62位到69位范围内的位用于指示压缩操作(302)已经执行。

19.根据权利要求18所述的方法，其特征在于包括，将UDP消息首部的从62到69位的至少一位设置为1的步骤。

20.根据权利要求13-19任何一项所述的方法，其特征在于，借助SNMP消息实现所述至少一个管理器对象(A)和所述至少一个中间对象(AG)之间的通信，并在压缩步骤期间包括以下步骤：

读取(100)完整的SNMP消息，

以十六进制格式编码(102)所读取的消息，以及

对以十六进制格式编码的消息进行压缩(104)。

21.根据权利要求13-19任何一项所述的方法，其特征在于，借助SNMP消息实现所述至少一个管理器对象(A)和所述至少一个中间对象(AG)之间的通信，并在接收步骤期间包括以下步骤：

将所接收的消息经过与所述压缩操作互补的解压(204)，以获取经过十六进制格式解码的消息，

从十六进制格式解码(202)该消息，以及

从所述解码的消息重组(200)整个SNMP消息。

22.根据权利要求20或21所述的方法，其特征在于包括，标准SNMP消息中的嵌套操作，用于传输经过所述压缩操作(104)的消息。

23.根据权利要求22所述的方法，其特征在于，在传输期间包括以下步骤：

按字节读取(108)经过所述压缩操作(104)的消息，并将其转换(110)为相应的ASCII字符消息，

产生(112)包括第一OID的变量绑定集，该第一OID指示原始文件大小和后续的OID/值对(pair)，该OID/值对携带经过所述压缩操作(104)并被转换为ASCII字符的部分所述消息。

重组SNMP消息首部数据，

以十六进制格式编码(114)所产生的SNMP消息，以产生UDP有效载荷，以及

传送(116)以此方式产生的UDP有效载荷。

24.根据权利要求22或23所述的方法，其特征在于，接收期间包括以下步骤：

接收经过所述压缩操作的消息作为UDP有效载荷(216)，

将以此方式接收的有效载荷经过十六进制解码操作(214)，

确认和组装(212)经过十六进制解码的消息的变量绑定，

将经过所述确认和组装操作(212)的消息经过二进制ASCII解码(210)，以及

将二进制形式的解码消息经过所述解压操作(204)。

25.根据权利要求20或21所述的方法，其特征在于包括，通过UDP嵌套整合经过所述压缩操作(104)的消息的步骤，用于传输经过所述压缩操作(104)的消息。

26.根据权利要求25所述的方法，其特征在于，传输期间包括以下步骤：

配置经过所述压缩操作(104)的所述消息作为一个协议数据单元(PDU)的有效载荷，以及

传送以此方式创建的有效载荷到给定的接收机端口。

27.根据权利要求25或26所述的方法，其特征在于，接收期间包括以下步骤：

接收所述消息作为在接收机端口收到的PDU UDP的有效载荷，以及

从所述PDU中提取所述有效载荷。

28.根据权利要求26或27所述的方法，其特征在于包括，发送一个SNMP类型的同步消息(1106)的步骤，该消息指示在所述至少一个管理器对象(A)和所述至少一个中间对象(AG)之间的所述发送端口和/或所述接收端口。

29.用于管理通信网络的系统，包括至少一个管理器对象(A)和至少一个被管对象(B1，...，BN)，其特征在于包括，实现根据权利要求1-28任何一项所述的方法的至少一个中间对象(AG)。

30.能直接载入至少一个计算机的内部存储器的软件模块，包括当该软件模块被至少一台计算机运行时，用于实现根据权利要求1-28任何一项所述的方法的部分软件代码。

Images