CN1750486A - 网络测量体系结构及其实现方法 - Google Patents

Abstract

本发明公开了一种网络测量体系结构。包括用户端模块、维护模块、调度模块、日程模块、执行模块、测量和分析模块，该维护模块被启动后读取各自的站点配置文件，主控站根据配置文件启动日程模块和调度模块，监控站则启动调度模块，使各模块进入阻塞状态，等待命令的到达；启动用户端模块后，用户登录并定制所需要的任务，发送到维护模块；维护模块将接收到的用户定制信息转发给调度模块，调度模块根据用户的选择启动相应的执行模块调用测量模块进行探测，并在测量完数据后启动的分析模块，将分析模块的结果存为可扩展置标语言XML文件，供用户使用。该体系结构是通过各模块的程序完成不同的功能来实现。具有很强的可扩展性灵活便捷的用户接口界面。

Description

网络测量体系结构及其实现方法

技术领域

本发明属于通信技术领域，涉及网络测量和分析，具体地说是一种网络测量体系结构及其实现方法。

背景技术

网络测量是指遵照一定的方法和技术，利用软件或硬件工具来测试或验证表征网络性能的指标的一系列活动的总和。网络测量是研究网络行为学(互联网运行规律的科学)的重要方法，对于网络运营、设备研制和网络技术与协议的研发都具有重要意义，对网络管理也具有重要的辅助作用。

现在的互联网规模越来越大，其性能的可知性越来越复杂，系统级的管理度也越来越小，而在实际网络运行中，互联网服务提供商需要通过网络性能测量系统来监测网络性能和网络行为特征，并根据测量数据配置和规划应用系统，使之提供更高的服务质量；网络用户需要通过测量应用系统的网络性能，确定应用系统是否提供了足够的网络服务质量，从而选择服务质量最佳的应用系统，所以对网络性能测量的研究随着互联网日益广泛的应用而变得越来越重要。

一些网络测量工具在功能和结构上有所不足，如对于每一个测量需求，都要部署一套测量工具，测量规模不易扩展，不能灵活配置，部署的测量工具只能测量某种特定应用系统的网络性能，缺乏测量业务种类扩展能力等。随着网络系统规模和业务种类的急剧增长，这种面向特定对象的性能评价手段在准确性和扩展性上越来越不能满足要求。

要解决这一问题，需要建立一个网络性能测量基础体系结构，为互联网性能和运行特征的研究提供一个可扩展的测量平台。

有关网络测量技术，国内外已进行了大量的研究，提出了很多的测量体系结构。国外具有代表性的是美国国家科学基金NSF(The National Science Foundation)和美国国防部高级研究项目署DARPA(The Defense Advanced Research Projects Agency)资助的国家Internet测量基础框架NIMI(National Internet Measurement Infrastructure)。NIMI项目开始由NSF支持，现在由DARPA支持。该NIMI测量系统建立在现有网络之上，它的体系结构类似于其他大型网络服务系统，如域名服务器DNS(Domain NameServer)，网络时间协议NTP(Network Time Protocol)和世界性的新闻组网络系统USENET，采用层次结构和分布式方式，使之可以扩展到整个互联网。该NIMI的测量技术主要采用主动测量技术，其评价指标主要有性能类指标。它在互联网中部署大量探针机器，探针机器之间相互合作交换测试流量从而监测互联网路径性能状况。目前探针机器采用的是Paxson通讯公司研制的网络探针进程NPD(Network Probe Daemon)，现有部署的NPD数量37个，测量路径达到1000条。该NIMI测量系统与其它几个测量体系结构不同的是，NIMI致力于建立可扩展互联网网络性能测量设施的通用体系结构，而不是为特定的分析目标做一组特定的测量操作，其探针是建立在NPD基础上，且由后台通信进程、任务调度、测量簇程序三部分组成，具有轻量级代码可移动，动态性，自动配置能力，对敏感数据的测量保证其私有性的安全性等优良特性。

国内具有代表性的网络测量体系，是北京航空航天大学提出的可定制的网络测量基础架构CNMI(Customizable Network Measurement Infrastructure)。CNMI的重要组成部分是测量探针结点，包括执行环境和探针模块集合，其探针具有分布性、实时性、指标的多样性和可扩展性，它基于J2SE(Java 2 Platform，Standard Edition)技术来实现跨平台的测量探针，

通过基于父子类的探针结构设计来实现探针的启动和管理，并由此实现CNMI的可扩展机制。参见张黎明.网络测量探针定制机制及探针执行环境研究.北京航空航天大学学位论文，万方数据。

上述测量体系结构的主要存在以下不足：

1.由于没有提出模块设计者自定制用户参数输入方式和自定制数据结果可视化形式的解决方案，因而不能定制测量指标，用户也不能添加自己想要而系统不存在的指标，缺乏面向应用需求的测量与分析方案的定制系统。

2.结构的分析方法比较零散，没有系统化地加入到体系结构中，测量项目主要限于时延、丢弃率、吞吐率等性能指标，没有考虑各种应用需求，如入侵检测，脆弱性度量等。

3.大多数结构都没有考虑结构的扩展性，没有考虑如何拓展体系结构使其它已有和将有的应用方便高效的加入到体系之中，没有或较少考虑各测量和分析方法之间数据的复用，数据利用率不高。

4.国内提出的CNMI测量结构虽说考虑了探针的扩展性，但其探针必须基于J2SE进行设计，必须实现父类的方法，这样限制了模块的开发工具，也限制了模块设计的灵活性，模块的系统集成与数据复用也很不方便。

发明的内容

本发明的目的在于克服上述已有技术的不足，提供一种能根据用户需求定制测量与分析方案，即具有很强包容性的分布式网络测量体系结构及其实现方法，以解决灵活适用场景和可扩展性的问题。

本发明的技术方案是这样实现的。

本发明的体系结构是一种基于层次式管理的分布式结构，即DNMAI(DistributedNetwork Measurement and Analysis Infrastructure)。该结构从整体上将各站点及其配给的模块分成主控站、监控站和探针三个大的层次。每个区域内部主控站与监控站以及下级主控站之间组成树形的隶属层次结构，一个区域可以拥有多棵树。区域之间由各树根组成一个类似对等网进行协调工作的网络。每个监控站管理多个探针。监控站负责响应主控站的配置与管理，探针的升级，启动，探针参数传入，和所得测量数据的传送与交流。探针则专注于所配置参数下自己领域的测量，必要时向监控站查询其他站点探针的位置并请求协调测量。

监控站负责响应主控站的配置与管理，探针的升级，启动，探针参数传入，和所得测量数据的传送与交流。

探针则用于在所配置的参数下的测量，必要时向监控站查询其他站点探针的位置并请求协调测量。

主控站了解整个DNMAI的拓扑结构并能进行相应的测量配置，同时提供网页服务向用户提供测量和分析接口，根据用户的选择和自身的配置以及策略文件定制出测量和分析流水工序的策略，然后调度相应的多个监控站或其它主控站完成探测，将结果存放到用户目录中供用户查看结果。主控站负责监控站的配置，提供探针的发放和下载，根据用户计划进行定期测量；主控站还具有互相协商进行大规模网络测量的功能。

用户登录根主控站来管理某个区域或整个网络的测量，网络的测量有其体系结构。

本发明的网络测量体系结构在主控站和监控站的各站点中，从程序实现上包括：用户端模块、维护模块、调度模块、日程模块、执行模块、测量和分析模块，首先启动各站点即所有主控站和监控站的维护模块，读取各自的站点配置文件，主控站根据配置文件启动日程模块和调度模块，监控站则启动其调度模块，各模块进入阻塞状态，等待命令的到达；当用户端模块被启动后，用户登录并定制所需要的任务，发送到维护模块；维护模块将接收到的用户定制信息转发给调度模块，调度模块根据用户的选择启动相应的执行模块；执行模块调用测量模块进行探测，并在测量完数据后启动相应的分析模块，将分析模块的结果存为可扩展置标语言XML文件，供用户使用。

本发明体系结构DNMAI的实现方法，是通过各模块的程序完成不同的功能，其中

维护模块，用于管理和分发各模块的消息并实现模块的更新；

调度模块，用于管理用户的账号信息、接收客户端测量计划、制定用户的任务计划、启动执行模块并根据用户的请求调用各模块的XSL文件进行转换、以及调用其它一些辅助模块进行辅助处理。

日程模块，用于负责读取由调度模块生成日程任务文件，定时或到达预定时刻后向调度模块发送消息来启动相应的探测任务；

执行模块，用于从命令行参数中解析XML文档，从解析的文档中得到测量模块或分析模块需要的参数，并按照参数的要求启动测量模块或分析模块来完成对应的测量任务或分析任务，并将结果转成适当的XML字符串，交给调度模块进行处理；

测量或分析模块，以动态连接库DLL形式或可执行文件EXE形式存在，该测量模块用于完成某一单一的测量任务，该分析模块负责完成对规定格式数据的某种特性分析，需要时由相应的执行模块载入并执行；

用户端模块，用于连接DNMAI主控站，得到各模块的参数定制页面，将对应的HTML加入到用户端页面中，然后收集用户进行的选择后，提交给主控站执行，最后将任务执行的结果页面显示到用户端页面中。

应用本发明的体系结构可以实现对网络测量的扩展，其扩展方法如下：

(1)编写一个执行模块解析XML文档形式的命令行参数，根据参数使用新执行模块执行所需要的测量或分析任务，任务完成后生成一个XML文档形式的结果；

(2)在DNMAI的模块信息文件中添加一个新的模块信息，描述所需要测量或分析任务模块所在路径、输入、输出、相关XSL格式文件及其它相关文件的信息；

(3)编辑一个生成所需要测量或分析任务参数输入界面的XSL文件，该文件能够生成一个给用户进行所需要测量或分析任务参数选择的HTML页面；

(4)编辑一个生成所需要测量或分析任务结果查看页面的XSL文件，该文件能够生成一个显示所需要测量或分析任务的运行结果的HTML页面；

(5)如果模块结果是放在内部目录中的，则还需要编写一个预处理模块，在用户查看结果之前将内部目录中的文件复制到公共目录中。

上述体系结构中的用户端模块由Java Applet，JavaScript脚本和相应的HTML页面组成，它与主控站的通信使用XML进行通信，并遵守DNMAI的通信约定。

上述方法中的维护模块管理和分发各模块消息的过程如下：

(1)启动维护模块，读取站点配置文件后进行初始化，

(2)启动调度模块和日程模块，并按如下过程创建侦听线程来侦听DNMAI的端口：

首先，从套接字上接收并解析XML文档，

接着，对解析成功的文档使用XML Schemas文件对该XML文档进行语法验证；

最后，将上述XML格式的消息放到对应模块的消息缓冲区中，以实现消息的转发；

(3)等待其它站点或其它模块的连接，并进入主消息循环，如果收到退出消息则退出DNMAI；

(4)当创建的侦听线程如果接收到连接，则创建一个消息处理线程处理该消息，原线程继续等待其它连接。

上述方法中的调度模块启动执行模块并根据用户的请求调用各模块的XSL文件进行转换的过程如下：

首先，接收并解析命令行XML文档，从中得到所有的配置信息；

然后，等待并解析发送到调度模块的XML消息，如果XML消息解析失败则返回；解析成功后使用XML Schemas文件对该XML消息进行语法验证；

最后，根据语法验证文件的节点名字分别对各模块进行处理。

本发明与现有技术相比具有如下优点：

(1)拥有很好的扩展性

由于现有的网络测量系统使用XML的大部分程序都直接使用Web服务器，将XML和XSL传到客户端让IE解释和处理，或者直接生成XML数据，然后通过一个XSL直接转换成HTML，送给客户端显示，由XSL控制着最终的界面，体现不出XML的可扩展性优势。而本发明的DNMAI结构是每个模块都有自己的XML和XSL文件，每个模块的XML数据结构和XSL界面形式都是可以独立设计的，然后在运行时由DNMAI依次转换处理每个模块的XSL，生成许多HTML片段，把它们传回客户端后拼在一起成为最终的界面，并通过嵌在客户端的Java Applet和JavaScript来配合完成这一过程，这样DNMAI在界面上就拥有很好的扩展性。

(2)具有灵活便捷的用户接口界面

用户可以通过该界面定制测量和分析方案，设置各测量模块的工作参数，并在测量过程中查看模块工作情况，在测量或分析完成后查看测量数据或分析结果。测量和分析模块则可以很方便的通过该接口获得用户的参数设置和参数选择，并在进行中和完成后能够给用户提供方便直观的数据结果和分析结果界面。

(3)有利于新模块的加入

本发明由于在内部模块间的消息传递中使用了XML进行表达的软件，可以方便的实现消息的分层处理，从而层次化模块功能，更利于模块的单独设计，而且这样模块间的协议也具有了可扩展性，方便了新消息的加入，更利于加入新模块。

(4)在数据的输入输出和消息处理机制上非常灵活

本发明由于对模块的启动采用XML格式的命令行方式传入参数，对模块的结果也建立XML索引进行管理，从而对模块的开发没有任何限制使得模块在数据的输入输出和消息处理机制上非常灵活，使得DNMAI具有很强的扩展性，对网络测量这样的架构软件非常适合。此外，测量和分析模块能简便有效地利用其它测量和分析模块的测量数据和分析结果。一个模块的结果可以被其它的模块复用，也可以使用其它模块的结果作为输入，甚至可以不需要用户通过界面设置参数而只需要其它模块的结果作为输入。

附图说明

图1是本发明的结构框图

图2是本发明各模块的运行总流程图

图3a是本发明维护模块的运行子流程图

图3b是本发明在维护模块中创建的消息处理线程的工作流程图

图4是本发明调度模块的运行子流程图

图5是本发明日程模块的运行子流程图

图6是本发明执行模块的运行子流程图

图7是本发明测量或分析模块的运行子流程图

图8是本发明客户端模块的运行子流程图

具体实施方式

以下结合附图详细说明本发明的结构及实现方法。

参照图1，本发明的体系结构是在包括主控站和监控站的网络各站点中分别设置软件包，作为测量平台以实现对网络的测量与性能分析。该软件包主要由维护模块、调度模块、日程模块、执行模块、测量和分析模块、用户端模块组成。各站点上的维护模块最先启动，它们读取各自的站点配置文件，然后根主控站根据配置文件启动日程模块和调度模块，监控站则启动其调度模块，启动后各模块进入阻塞状态，等待命令的到达。

工作时，首先启动用户端模块使用户登录，由用户定制需要进行的任务，之后，用户端模块通过Java Applet程序将定制的任务消息发送到维护模块，通过维护模块将该任务消息转发给调度模块，调度模块再根据用户的选择启动相应的执行模块，通过执行模块调用测量模块进行探测，最后在测量完数据后启动相应的分析模块，并将分析模块的结果存为XML文件，供用户使用。

参照图2，本发明给出了一个启动模块的例子，其工作过程是：当用户端模块被启动后，用户登录DNMAI主控站，得到DNMAI的HTML页面并在用户端模块上运行。用户定制完需要进行的任务后，用户端模块的Java Applet程序将此消息发送到主控站的维护模块，维护模块将消息转发给调度模块，调度模块根据用户的选择启动相应的执行模块。图2中被启动的第二执行模块2由于需要监控站的配合来进行测量活动，所以向相应的DNMAI监控站的维护模块发送消息，同样监控站维护模块收到后将消息转发给调度模块，调度模块根据消息启动监控站上的第二执行模块2，被启动的模块根据启动参数了解到自己是被远程启动的，因此启动监控站上的测量模块进行探测，并将测量数据传回主控站上的第二执行模块2。主控站上的第二执行模块2得到监控站的测量数据后启动相应的分析模块，并将分析模块的结果存为XML文件。图2中第一执行模块1由于可以直接在主控站完成所有任务，所以直接调用主控站上的测量模块进行探测，然后将结果存为XML文件。之后用户端模块向主控站的维护模块发送消息要求查看任务结果，该消息被转发到主控站的调度模块，调度模块调用相应模块的XSL文件得到结果页面并传回用户端模块，用户就可以看到任务执行结果了。

参照图3a，本发明的维护模块在站点的DNMAI端口上进行侦听，所有消息的传输开始阶段都需要先经过维护模块，因此维护模块的一个重要功能就是管理和分发各模块的消息。DNMAI中调度模块给启动的每一个模块都会分配一个“runtime_id”编号，并维护一张“运行时模块信息描述表”，DNMAI通过此编号来标识正在运行的每个模块，并根据此编号来管理模块间的消息。维护模块通过查看这张表来实现消息的分发。维护模块的另一个重要功能是实现模块的更新，DNMAI中的每一个模块都是可以升级的，维护模块可以根据模块的版本号向上级站点请求下载最新版本的文件来进行更新，由于每个站点都有维护模块，所以可以形成一级级的递级更新，最后所有DNMAI站点的文件都与主控站的文件一样。该模块的工作流程如下：

首先启动维护模块，读取站点配置文件后进行初始化，启动调度模块和日程模块，然后创建侦听线程来侦听DNMAI的端口，等待其它站点或其它模块的连接，这时则进入主消息循环，如果收到退出消息则退出DNMAI。当创建的侦听线程如果接收到连接则创建一个消息处理线程处理该消息，原线程继续等待其它连接。

参照图3b，在维护模块中创建的消息处理线程的工作流程如下：

首先，从套接字上接收并解析XML文档，接收过程中以连续8字节的0x01表示XML文档的结束，XML消息之间两字符的最大传输间隔不能超过10秒，否则连接断开，解析成功后使用XML Schemas文件对该XML文档进行语法验证，如果XML解析失败或者验证失败都立即断开连接。

其次，验证的Schema文件，在用来进行语法验证的Schema文件中，我们定义传给维护模块的XML消息根节点必须是<dnmai>，根节点下的第一个节点可在下面3种节点中选其一，分别是<maintain>，<transfer>和<module_msg>。后面两个节点分别表示该消息需要转发到调度模块和转发到其它模块中去，而第一个节点<maintain>则表示此消息是一个维护消息，是发送给维护模块的。如果是维护消息则其后的节点可以是<download_by_module_id>或<download_by_filename>，分别表示根据模块ID号更新文件和根据文件名更新文件，它们都有“version”和“hand_on”属性来表示所请求文件的版本要求，以及本站更新失败时是否向更高一级站点请求更新。如果是需要转发给调度模块或其它模块的消息则可以是3种类型的消息：字符串消息，BASE64编码格式的消息和XML格式的消息，分别用节点<message_ascii> ，<message_base64Binary>和<message_xml>来表示，目前调度模块只接受XML格式的消息。

最后，由维护模块会将上述节点中的消息放到对应模块的消息缓冲区中以实现消息的转发。

参照图4，本发明的调度模块是DNMAI的核心，它负责管理用户的账号信息，接收客户端测量计划，制定用户的任务计划，并根据计划启动执行模块。其间还需要根据用户的请求调用各模块的XSL文件进行转换，给用户端传回相应的HTML页面，以及调用其它一些辅助模块进行辅助处理。在执行模块执行完毕后需要回收执行模块所占用的资源，同时启动任务计划中下一个满足要求的模块，并为之分配资源(如消息缓冲区等)。如果是远程模块的请求，需要根据请求启动相应的模块，并在进程结束时回收资源。另外如果要启动的模块在站点上不存在，则需要通知维护模块进行模块升级。以上动作失败时均需要给请求方返回出错信息。该模块的工作流程如下：

首先，接收并解析命令行XML文档，从中得到所有的配置信息，然后等待并解析发送到调度模块的XML消息，如果XML消息解析失败则返回，解析成功后使用XMLSchemas文件对该XML消息进行语法验证，在用来进行语法验证的Schema文件中，我们定义传给调度模块的XML消息根节点必须是<dnmai>，根节点下的第一个子节点必须是<msg_from>，此子节点的内容表示消息发送者的模块类型，可以是“web applet”，“local_maintain”，“local_exec_module”，“remote_exec_module”或“schedule_module”；其分别表示为客户端模块，本地站点的维护模块，本地站点的执行模块，非本地站点的执行模块，日程模块。

然后，根据第二个子节点的名字分别进行处理，如果接收的本地站点的维护模块的XML消息中第二个子节点是<quit>，那么就退出调度模块。

参照图5，本发明的日程模块负责读取日程任务文件(该文件由调度模块生成)，定时或到达预定时刻后向调度模块发送消息来启动相应的探测任务。该模块的工作流程如下：

首先，读取日程任务XML文档，从中得到日程任务的信息，当需要启动探测任务时，就向调度模块发送消息来启动相应的探测模块进行探测；

然后，确定是否退出，即如果向调度模块发送消息失败则返回，如果收到本地站点的维护模块的退出信息，那么就退出日程模块。

参照图6，本发明的执行模块主要任务是从命令行参数中解析XML文档，其中XML是eXtensible Markup Language的英文缩写，意为可扩展置标语言。从解析的文档中得到测量模块或分析模块需要的参数，并按照参数的要求启动测量模块或分析模块来完成对应的测量任务或分析任务。最后还需要将结果转成适当的XML字符串，交给调度模块进行处理，同时通知调度模块所规定的任务已经完成。如果需要进行的任务是一个分布式的任务则需要通知其它站点启动相应的执行模块来进行分布式测量，对于对方站点上由此而被启动的执行模块来说则需要配合启动方来完成分布式测量。如果任务较为复杂，需要在测量过程中与其他执行模块进行信息交换，则应按照DNMAI的约定方式进行通信。执行模块的存在主要是为了各种测量模块和分析模块能向调度模块提供统一的调用接口，向其它模块提供统一的通信接口。如果模块的功能较简单，可以和相应的测量模块或分析模块合并成一个模块。该模块的工作流程如下：

首先，解析命令行XML文档，从中得到测量模块或分析模块需要的参数，如果需要使用其它模块的结果作为输入参数，那么在该执行模块的<inputs>节点中添加子节点，添加的子节点名称就是要使用文件的文件名；

然后，按照参数的要求启动测量模块或分析模块来完成对应的测量任务或分析任务，任务完成后将结果XML文档交给调度模块进行处理，提交完后退出执行模块；

如果需要进行的任务是一个分布式的任务则首先与相应站点的维护模块建立TCP连接，然后通知其调度模块启动相应的执行模块来配合启动方完成分布式测量，任务完成后将结果XML文档交给启动方的调度模块进行处理，提交完后退出执行模块。

参照图7，本发明测量或分析模块负责完成某一单一的测量任务，例如单点拓扑发现模块负责测量当前主机附近的拓扑数据。分析模块负责完成对规定格式数据的某种特性分析，如非线性测验。这些模块通常以动态连接库(DLL)形式(Linux中则对应为so形式)或可执行文件(EXE)形式存在，其形式由相应的执行模块决定，它们在需要时由相应的执行模块载入并执行。该模块的工作流程如下：

首先，解析命令行XML文档，从中得到测量或分析模块需要的输入参数；

然后，将参数输入执行测量分析的程序中，执行测量分析任务，任务完成后将结果XML文档交给其执行模块进行处理，提交完后退出测量或分析模块。

参照图8，本发明的用户端模块由Java Applet，JavaScript脚本和相应的HTML页面组成。在用户端模块中，用户端程序负责连接DNMAI主控站，得到各模块的参数定制页面，将对应的HTML加入到用户端页面中，然后收集用户进行的选择，将这些选择提交给主控站执行，最后将任务执行的结果页面(图表，曲线，图像等)显示到用户端页面中。它与主控站的通信也是使用XML进行通信，并遵守DNMAI的通信约定。该模块的工作流程如下：

首先，打开DNMAI用户端模块登录DNMAI，选择要定制的任务，为这些任务填写或选择适当的输入参数，定制完任务后就可以提交任务，提交时用户端模块将调用各模块嵌入的JavaScript脚本验证输入参数的有效性；

然后，用Java Applet程序将所定任务和参数发送给主控站，如果数据非法或不在有效范围内则提示用户进行修改，验证成功后用户端模块把定制的任务用Java Applet程序发送给主控站，并返回任务浏览页面，刷新用户的任务执行情况，等待任务执行完成；

最后，解析结果XML文档，当任务完成后，用Java Applet程序解析结果XML文档，而用户端模块嵌入的JavaScript脚本负责将任务结果动态生成的内容插入到供用户查看的HTML结果页面的适当部分加以显示，如果需要，用户可以在结果的HTML页面中下载测量数据或分析结果。

本发明具有很强的可扩展性，即应用本发明的体系结构可以通过添加新的模块实现对网络的不同任务进行测量。

实例1

把实现分布式拓扑发现的测量模块添加到DNMAI中，完成对分布式拓扑发现的测量，其过程如下：

(1)编写一个执行模块解析XML文档形式的命令行参数，根据参数使用新执行模块执行分布式拓扑发现测量或分析任务，任务完成后生成一个XML文档形式的结果；

(2)在DNMAI的模块信息文件中添加一个新的模块信息，描述分布式拓扑发现测量模块所在路径，所需的输入和能产生的输出，相关XSL即用来将XML转换为HTML或者PDF等其他格式文件，及其它相关文件的信息；

(3)编辑一个生成分布式拓扑发现的参数输入界面的XSL文件，该文件能够生成一个给用户进行分布式拓扑发现参数选择的HTML页面；

(4)编辑一个生成分布式拓扑发现的结果查看页面的XSL文件，该文件能够生成一个显示分布式拓扑发现的运行结果的HTML页面；

(5)如果模块结果是放在内部目录中的，则还需要编写一个预处理模块，在用户查看结果之前将内部目录中的文件复制到公共目录中。

上述步骤(1)中执行模块启动参数的设计：

为了能进行以上5个步骤，需要先设计拓扑发现模块的输入参数格式。

在设计的拓扑发现模块的输入参数格式里，每一个<probe>节点表示一个需要进行单点拓扑发现的探测点，其“ip”属性表示探测点的IP地址，其子节点表示每个探测点的起始目标和探测时长，<probe>节点的数量根据用户选择的探测点数量而定。

上述步骤(2)编写分布式拓扑发现的执行模块：

在适当的时候调度模块将调用分布式拓扑发现执行模块进行探测，进程启动时的命令行参数是一些站点配置信息，以及前面参数输入界面中“GetTaskStartParam_@taskid”函数返回的启动参数。由于分布式拓扑发现模块不需要其它模块的输出结果作为输入，所以<start_param>节点的内容与“GetTaskStartParam_@taskid”函数返回的<start_param>完全相同，如果执行模块的输入参数需要使用其它任务的结果作为输入，则调度模块会将<start_param>节点处理后再传给执行模块。

DNMAI运用将执行模块制作成动态链接库DLL的形式来启动执行模块，调度模块会先启动一个默认的载入程序，该载入程序会先作一些初始化工作，解析命令行参数，然后调用执行模块DLL的SetDnmaiParam函数将一些常用变量、常用函数以及解析命令行生成的XML文档告诉执行模块，然后调用执行模块的RunTask函数将控制权交给执行模块，执行模块可以通过传入的常用函数来管理模块消息。

执行模块共需导出两个函数：SetDnmaiParam和RunTask。

函数SetDnmaiParam非常简单，将载入程序传入的指针参数保存到全局变量即可，RunTask函数中通过此全局变量使用其中的变量和API函数。

RunTask函数管理整个分布式探测过程，期间需要启动各探测点所在站点的拓扑发现执行模块，这些被远程启动的模块并不需要管理分布式探测，而只需要在其本地进行单点拓扑发现并传回探测结果即可，因此RunTask函数启动后需要先了解自己是否是被远程启动的。这可以通过查看命令行参数中“dnmai/caller”节点的值来得到，如果是被远程启动的其值为“remote module”，否则为“user task”。

如果是本地启动的，RunTask首先查看是否需要更新拓扑可视化模块，如果拓扑可视化模块不存在则通过调用传入的DNMAI API函数进行模块更新。然后依次发送消息到各探测点的调度模块，发送消息也是使用DNMAI API，请求启动其拓扑发现执行模块，其参数是用户为各探测点设置的探测参数。在开始等待各探测点发回探测结果时，如果等待超时则记录超时结果后退出，其超时阀值是所有探测点中最长探测等待时间加几分钟冗余时间。等待中如果收到探测点的探测结果则将它们保存到用户目录中，然后调用拓扑可视化模块得到拓扑图，同样保存到用户目录中，再检查是否所有探测点的探测结构都已接收，如果不是则继续等待。如果所有探测点都已探测完毕，则调用拓扑可视化模块综合所有得到的拓扑，生成拓扑图保存到用户目录。RunTask退出前需要发送消息到调度模块通知调度模块拓扑发现模块已经运行完毕，准备退出，退出消息中执行模块的执行结果放到<results>节点中。

如果是因远程模块请求而启动的，RunTask先查看是否需要更新单点拓扑发现模块，同样如果需要则调用DNMAI API函数更新之，然后使用传过来的起始目标地址参数进行单点拓扑探测，并等待指定的探测等待时间，时间到达后停止探测，将得到的拓扑结果条目逐一转换成BASE64编码通过发送消息传回原启动方。传送完成后就可以退出了，同样退出前需要通知本地调度模块以释放进程资源。

上述步骤(3)中编写生成参数输入界面的XSL文件：

在确定了执行模块的输入参数格式之后就可以编辑生成参数输入界面的XSL文件了，它的目的就是允许用户选择和输入上面的几个参数，然后在用户提交任务时生成上面XML形式的字符串。

XSL的输入文件还有一个<task>节点表示相关的任务信息，其有一个最重要的属性是“taskid”，表示调度模块给本次任务分配的任务号，它还有其他一些子节点表示任务的其它信息，如<inputs>节点是满足任务输入条件的其它任务的集合，由于分布式拓扑发现模块不需要以其它任务的结果作为输入，所以不关心此节点。

在生成参数输入界面的XSL文件中还需要在页面的<script>元素中定义3个JavaScript脚本函数，用于客户端模块在适当的时候调用，它们分别以“IsTaskParamValid_”、“GetTaskSelectedHtml_”和“GetTaskStartParam_”打头。为了避免各个任务的函数重名冲突，每个函数的函数名都加上任务的“taskid”属性作为各自的函数名。“IsTaskParamValid_@taskid”函数在用户提交任务之前被调用，用于检查用户输入的参数是否合法，合法应返回字符串“true”，否则应提示用户数据的合法的形式并返回“false”，该函数是可选的，但DNMAI强烈推荐实现该函数，在接受用户输入的参数前检查其合法性。

“GetTaskSelectedHtml_@taskid”函数在用户临时确认了该任务的选择后被调用，该函数是可选的，缺少该函数时DNMAI把界面上的所有控件的“disabled”属性设为真来禁止用户再对参数进行修改，如果实现该函数，则应返回新的HTML页面代码，用户不能再编辑该页面上的参数。

“GetTaskStartParam_@taskid”函数在用户提交任务时被调用，用于得到模块的启动参数。该函数应该根据用户输入的参数返回模块将要使用的XML形式的启动参数，在这里，XSL文件将把用户选择的探测点的IP地址，各探测点对应的起始目标和探测时长依次填入上面设计的<start_param>节点中，返回其字符串。该函数是必须实现的，否则DNMAI不能正常工作。

XSL文件可以先用FrontPage之类的工具编辑出界面，然后在源代码中加入XSLT语句，加以改造，变成XSL文件。

上述步骤(4)编写生成结果查看页面的XSL文件：

用户查看拓扑探测的结果时调度模块将调用XSL文件来生成结果页面，其传入的参数是站点配置文件的副本，并在配置文件中加入要显示结果的任务节点，而任务节点包括任务的起始参数，即在<start_param>节点中和拓扑探测生成的结果即在<results>节点，<results>节点已经经过了预处理模块的处理，其文件路径已经换成了互联网可访问的URL形式。

拓扑发现模块可以让用户下载测得的拓扑数据，同时直接显示拓扑图，点击拓扑图则可以直接下载拓扑图。

生成结果查看页面的XSL文件中同样可以加入JavaScript脚本来进行更灵活的页面操作，以更直观生动的方式来表达测量数据和分析结果。

上述步骤(5)中编写分布式拓扑发现的结果查看预处理模块：

当用户要查看分布式拓扑发现的结果时DNMAI会先调用预处理模块对探测结果进行预处理，然后再将处理后的结果传给生成结果页面的XSL文件。由于在分布式拓扑发现执行模块中将拓扑数据和拓扑图放在了用户目录中，而该用户目录是不能通过互联网访问的，所以在预处理模块中需要将这些数据和图片复制到公共目录中，并更改探测结果中的文件路径，这样用户就可以通过互联网访问这些数据了。

预处理模块需要导出一个ResultProcess函数，调度模块将调用此函数对任务结果进行预处理，它有3个参数，分别是待处理的任务节点的副本，用户目录文件的位置，以及DNMAI的站点配置文件。从站点配置文件中可以通过路径“dnmai/stations/public_data_dir”得到公共目录的位置，使用CopyFile函数即可将用户目录中的文件复制到该目录下，在站点配置文件中通过访问路径“dnmai/stations/public_dir_url”的内容即可得到公共目录在互联网中的链接表示，它是类似“Http：//www.xidian.edu.cn/.../”的URL链接，用它作为前缀加上前面复制后的文件名就可以让用户通过互联网来访问这些文件了。

为了增加文件安全性，拓扑发现的预处理模块在各文件名前加一串随机字符串作为文件复制后的新文件名。

实例2

把测量端到端时延的测量模块添加到DNMAI中，完成对端到端时延的测量，其过程如下：

(1)编写一个执行模块解析XML文档形式的命令行参数，根据参数使用新执行模块执行端到端时延的测量或分析任务，任务完成后生成一个XML文档形式的结果；

(2)在DNMAI的模块信息文件中添加一个新的模块信息，描述测量端到端时延的测量模块所在路径，所需的输入和能产生的输出，相关XSL即用来将XML转换为HTML或者PDF等其他格式文件、及其它相关文件的信息；

(3)编辑一个生成测量端到端时延的参数输入界面的XSL文件，该文件能够生成一个给用户进行测量端到端时延参数选择的HTML页面；

(4)编辑一个生成测量端到端时延的结果查看页面的XSL文件，该文件能够生成一个显示测量端到端时延的运行结果的HTML页面；

(5)如果模块结果是放在内部目录中的，则还需要编写一个预处理模块，在用户查看结果之前将内部目录中的文件复制到公共目录中。

上述实施例2中执行模块启动参数的设计、编写生成参数输入界面的XSL文件、编写测量端到端时延的执行模块、编写测量端到端时延的结果查看预处理模块的方法与

实施例1相同。

本发明的扩展不限于上述两种实施例，对本领域的技术人员来说在了解本发明的技术方案后，完全可以做出各种细节上的修改，以实现不同任务的网络测量和扩展，但这些应用和修改均在本发明的保护范围之内。

Claims (7)

1.一种网络测量体系结构，在主控站和监控站的各站点中，从程序实现上包括：用户端模块、维护模块、调度模块、日程模块、执行模块、测量和分析模块；该维护模块被启动后，读取各自的站点配置文件，主控站根据配置文件启动日程模块和调度模块，监控站则启动其调度模块，各模块进入阻塞状态，等待命令的到达；当用户端模块被启动后，用户登录并定制所需要的任务，发送到维护模块；维护模块将接收到的用户定制信息转发给调度模块，调度模块根据用户的选择启动相应的执行模块；执行模块调用测量模块进行探测，并在测量完数据后启动相应的分析模块，将分析模块的结果存为可扩展置标语言XML文件，供用户使用。

2.根据权利要求1所述的网络测量体系结构，其中用户端模块由Java Applet，JavaScript脚本和相应的HTML页面组成，它与主控站的通信使用XML进行通信，并遵守DNMAI的通信约定。

3.实现权利要求1体系结构的方法，是通过各模块的程序完成不同的功能，其中：

维护模块，用于管理和分发各模块的消息并实现模块的更新；

调度模块，用于管理用户的账号信息、接收客户端测量计划、制定用户的任务计划、启动执行模块并根据用户的请求调用各模块的XSL文件进行转换、以及调用其它一些辅助模块进行辅助处理；

日程模块，用于负责读取由调度模块生成日程任务文件，定时或到达预定时刻后向调度模块发送消息来启动相应的探测任务；

执行模块，用于从命令行参数中解析XML文档，从解析的文档中得到测量模块或分析模块需要的参数，并按照参数的要求启动测量模块或分析模块来完成对应的测量任务或分析任务，并将结果转成适当的XML字符串，交给调度模块进行处理；

测量或分析模块，以动态连接库DLL形式或可执行文件EXE形式存在，该测量模块用于完成某一单一的测量任务，该分析模块负责完成对规定格式数据的某种特性分析，需要时由相应的执行模块载入并执行；

用户端模块，用于连接DNMAI主控站，得到各模块的参数定制页面，将对应的HTML加入到用户端页面中，然后收集用户进行选择后，提交给主控站执行，最后将任务执行的结果页面显示到用户端页面中。

4.根据权利要求3所述的方法，其中维护模块管理和分发各模块消息的过程如下：

(1)启动维护模块，读取站点配置文件后进行初始化；

(2)启动调度模块和日程模块，并按如下过程创建侦听线程来侦听DNMAI的端口：

首先，从套接字上接收并解析XML文档；

接着，对解析成功的文档使用XML Schemas文件对该XML文档进行语法验证；

最后，将上述XML格式的消息放到对应模块的消息缓冲区中以实现消息的转发；

(3)等待其它站点或其它模块的连接，并进入主消息循环，如果收到退出消息则退出DNMAI；

(4)当创建的侦听线程如果接收到连接，则创建一个消息处理线程处理该消息，原线程继续等待其它连接。

5.根据权利要求3所述的方法，其中调度模块启动执行模块并根据用户的请求调用各模块的XSL文件进行转换的过程如下：

首先，接收并解析命令行XML文档，从中得到所有的配置信息；

然后，等待并解析发送到调度模块的XML消息，如果XML消息解析失败则返回，解析成功后使用XML Schemas文件对该XML消息进行语法验证；

最后，根据语法验证文件的节点名字分别对各模块进行处理。

6.应用权利要求1对网络测量实现扩展的方法，按如下过程进行：

(1)编写一个执行模块解析XML文档形式的命令行参数，根据参数使用新执行模块执行所需要的测量或分析任务，任务完成后生成一个XML文档形式的结果；

(2)在DNMAI的模块信息文件中添加一个新的模块信息，描述所需要测量或分析任务模块所在路径、输入、输出、相关XSL格式文件及其它相关文件的信息；

(3)编辑一个生成所需要测量或分析任务参数输入界面的XSL文件，该文件能够生成一个给用户进行所需要测量或分析任务参数选择的HTML页面；

(4)编辑一个生成所需要测量或分析任务结果查看页面的XSL文件，该文件能够生成一个显示所需要测量或分析任务的运行结果的HTML页面；

(5)如果模块结果是放在内部目录中的，则还需要编写一个预处理模块，在用户查看结果之前将内部目录中的文件复制到公共目录中。

7.根据权利要求6所述的扩展方法，其中步骤(3)中编写生成参数输入界面的XSL文件的过程如下：

首先，编写允许用户选择和输入参数的控件；

然后，在参数输入界面的XSL文件的<script>元素中定义3个JavaScript脚本函数，它们分别以“IsTaskParamValid_”、“GetTaskSelectedHtml_”和“GetTaskStartParam_”打头，每个函数的函数名都加上任务的“taskid”属性来作为各自的函数名，其中，“IsTaskParamValid_@taskid”函数在用户提交任务之前被调用，用于检查用户输入的参数是否合法，“GetTaskSelectedHtml_@taskid”函数在用户临时确认了该任务的选择后被调用，用于禁止用户对参数进行修改，“GetTaskStartParam_@taskid”函数在用户提交任务时被调用，用于得到模块的启动参数。

Images