分布式知识体系（精选4篇）
分布式知识体系 篇1
0 引言
基于信誉的信任管理理论和技术作为分布式应用环境的安全研究领域,近年来引起了众多信息安全研究人员的关注,其原因是传统的基于密码学的“硬安全”理论和技术主要解决网络环境中安全传输、授权和存取控制等问题,而在诸如网格、P2P系统和Ad hoc网络以及分布式探测网络等分布式应用系统中,节点都是自治的,它们在动态和不确定环境下实现其设计目标,而整个系统的功能是多个节点彼此反复地交互作用以共享信息、知识和任务来实现。这些节点在没有集中协调控制的情况下,根据自身的观点和策略自行做出本地决策,开放和匿名特性使得系统中的节点容易受到来自恶意用户的攻击。因此,系统中需要一种信任机制来抑制这些恶意节点的行为,激励诚实行为。研究人员提出了基于信誉的“软安全”机制来解决信任问题,提出了“硬安全”和“软安全”概念并指出它们的区别:“硬安全”是指传统的安全机制,如加密机制、认证机制和存取控制等,而“软安全”是指社会控制机制,如信誉或信任机制;如果一些人发现绕过硬安全机制的方法,那么硬安全是容易受到攻击的,而软安全允许一切行为,只要该行为是好行为。基于信誉的信任管理系统使得一个节点能够评估另一个节点的可信度,这种评估是基于来自系统中其他节点交互反馈的相关信息。系统使用不同的机制获取信誉信息并决定信任。近年来研究者着眼于信任管理模型的研究,如何把信任管理模型集成到分布式应用系统中,也需深入研究和探讨。
由于分布式应用系统的分布式结构和开放特性,节点间的直接交互是非常有限的,服务需求节点需要系统中其他节点的推荐信息来计算待交互节点的本地信任值。而且,节点存在自私和恶意行为,节点的推荐信息就会存在噪音。如何去除这些噪音,从而有效聚集推荐信息获得待交互节点的信誉引起了研究者的广泛关注。本文根据信息论中的相对熵计算推荐节点提供信息的质量,计算方法简单有效。
1 分布式信任管理系统体系结构
基于信誉的信任管理是分布式应用环境内在组成部分,为分布式环境中的节点间交互和合作提供基于信任值的决策机制。我们在分布式应用网络层(如P2P网络)之上增加信任层,信任层用于管理节点间的信任关系,而信任层节点间有向边的权重标示节点间的信任值,应用网络层节点间边表示节点间的连接关系。分布式应用网络层用于管理服务搜索和交互结果存储等方面,如图1所示。在图1的基础上,综合文献[1,6],我们提出了层次化的分布式信任管理体系结构,该结构主要由应用环境层、统一信任管理层、服务支持层和通信管理层组成,如图2所示。
1.1 应用环境层
应用环境层AEL(Application Environment Layer)主要包括应用信任策略、上下文管理和节点标示管理单元。应用信任策略单元根据统一信任管理层已经实施的信任管理系统的类型,为应用系统提供相应的信任策略机制,以及不同上下文环境下信任机制的映射。
上下文管理实现节点对上下文的感知、选择和适应。根据文献[7],简单地说,上下文就是一个节点所处的环境,上下文服务就是节点在特定环境下所能得到的服务和它所能提供的服务,一个上下文是属性集及其在一个环境中的实例值,所有属性集可能是可数无穷的。具体的应用环境是通过上下文管理单元来体现的。
数字标示是与一个主体或实体紧密相关的持久的属性集,这个主体或实体可以是人、组织、软件程序和终端计算机等。标示管理是指计算机网络中数字标示的创建、使用、管理和撤销等处理过程。信任管理本质是管理节点数字标示间的信任关系,所以在应用环境中必须构建标示管理单元。
1.2 统一信任管理层
构建统一信任管理层UTML(Unified Trust Management Layer)是为了业务应用环境能够更好地利用信任管理系统(TMS)提供的信任值而提出并实现的一个面向应用的“透明”中间层。它介于服务支撑层与具体业务应用中间,通过对不同应用系统中所需信任安全策略的抽象,为具体的应用透明地使用TMS信任安全服务提供接口。它主要由信任测度表示、信任计算、信任决策和信任系统评估四个单元组成。
研究者已经提出了许多信任测度表示方法,总的来说主要有三种:连续型、离散型和文字或符号表示型。
信任计算单元组合各种信任信息源和模型本身的信息聚集算法,计算出需求节点与待交互节点间的信任值。信任计算的信息源主要有三种,如图3所示,个体源是指两个节点间的直接交互信息源,通过直接交互,节点可以获得其他节点的最可靠信息。社会源是指如果一个节点与其待交互节点间没有直接交互信息,那么该节点设法从系统中的其他节点处获得待交互节点的相关信息。本体源是指系统中节点间的语义关系,通过语义关系可以定位节点在系统重点的角色,进而体现节点的可信度。
信任决策是根据信任计算单元计算出的信任值和模型中提供的交互信任阀值,决定是否与待交互节点进行本次交互,若进行交互,需要对本次交互的结果进行等级评价,并把等级评价信息传输给服务支撑层的数据存储单元,整个信任决策过程如图4所示。
信任模型评估是根据应用环境使用信任模型后的反馈信息,对信任管理模型进行评估,以便动态调整信任模型中的相关参数,使信任模型更能适应应用环境的需求。
1.3 服务支撑层
构建服务支撑层SSL(Service Support Layer)有助于把信任管理子系统从潜在的服务搜索和信息检索等机制中独立出来,从而便于信任管理和服务管理分开独立研究,同时,也便于某种信任管理系统嵌入到不同分布式应用环境中。
服务抽象为分布式网络环境下可以共享和利用的任何能力。服务发现是指服务需求节点能根据服务支撑层的服务查询算法,快速有效地寻找到其所需要的服务。服务通告是指当一个节点进入分布式网络环境后,通过服务支撑层的服务通告算法向网络发布其可以提供的服务。不同的分布式网络环境有其特有的服务发现和通告机制,分布式信任管理系统利用这些机制实现节点间的服务交互。
数据存储是利用分布式数据存储方法(如基于DHT的数据存储方法)实现节点间交互反馈数据(如等级评价数据)的安全、高效和冗余存储,同时便于UTML层的数据存取。
安全管理实现服务支撑层涉及到的各种安全机制,如密钥管理、证书管理和数据存储安全机制等。
在分布式服务网络中,需要构建激励机制,鼓励网络中的节点积极参与服务交互以及及时准确提供服务交互结果的反馈。交互反馈是分布式信任管理中及其重要的数据源,没有交互反馈,就无法构建节点间的信任关系。
1.4 通信管理层
CML(Communication Management Layer)负责实现分布式应用系统中节点间透明通信,而无须了解具体底层实现通信的相关技术。安全管理负责通信管理层的相关安全机制,如通信信道的加密机制和数字签名机制等。
2 仿真实现和性能评价
2.1 仿真模型的建立
我们使用多代理仿真系统Re Past[9]作为我们的仿真平台。在我们的仿真中,利用Re Past的社会网络构造库,构建一个具有小世界特性的P2P覆盖网络[10],其中每个节点既是服务的需求者,也是服务的提供者。P2P覆盖网络实现分布式信任管理体系结构中的服务支撑层的服务发现和通告、数据存储、安全管理和激励机制等功能。在P2P覆盖网络之上构建一个信任关系网络,实现统一信任管理层的信任测度表示、信任值计算、信任决策和信任系统评估等功能。本文的仿真模型重点实现本文提出的层次化分布式信任管理结构中的UTML和SSL的部分功能模块,其他功能模块和应用环境层及通信管理层没有特别探讨和实现,可以利用分布式网络环境中现有技术来实现。为了减少“搭便车”(Free-rider)和sybil攻击[3],本文提出了有偿服务模式,即服务需求者需向服务提供者支付与服务质量相当的费用。
2.2 信任值计算方法
在分布式信任管理系统研究中,我们更多地关注交互结果,不关注交互过程。当一个服务需求节点接收到一个服务提供节点的服务时,我们就认为成功地完成了一次交互,否则此次交互是失败的。此处的一个重要假设是节点间交互本质上是原子的[11],即节点间的一次交互要么完全执行,要么根本就没发生。因为我们知道节点所依托的网络及其生存环境存在潜在的不可靠性,随时都会发生故障,从而影响节点间交互的完整性。据此,我们使用二进制等级评价方法(也称作Beta等级评价系统)[12],即用1表示交互成功,0表示交互失败,那么节点间交互的历史记录就是0或1组成的随机串。
根据文献[12],节点A与节点B进行交互成功的概率为:
其中Γ(·)为Gamma函数,N1和N0分别为节点A计算节点B信任时可聚集到的“1”的数量和“0”的数量。
节点A对节点B的信任评估就是与节点B进行交互成功的概率。因此,节点A对节点B的信任评估就是Beta分布的期望值:
由式(2)可知,节点A与节点B进行交互成功的概率与参数p无关,而与N1和N0的取值紧密相关。当N1=N0时,E(beta(p|N1,N0))=0.5,表明节点A很难决定节点B行为的可信度,因为根据文献[13],此时信息熵最大,那么交互的不确定性就最大;当N1>N0时,E(beta(p|N1,N0))>0.5,表明节点B行为较可信,E(beta(p|N1,N0))值越高,节点B的行为越可信;当N1<N0时,结果就相反。
2.3 等级评价过滤和聚集
由于分布式网络的分布式结构和开放特性,单凭节点A与节点B的直接历史交互记录很难准确评估节点B的真实信任,我们需要组合节点A的邻居节点X(即节点A中所保存的与其交互,同时也与节点B交互的节点集)所提供的推荐信息。节点存在自私和恶意行为,节点的推荐信息就会存在噪音,如何去除这些噪音,从而有效聚集推荐信息获得待交互节点的信任值。根据前面所述的二进制等级评价方法,节点间交互的历史记录就是0或1组成的随机串。那么节点的直接交互历史记录是基于Ω={0,1}上的一个随机分布,而间接交互也是Ω={0,1}上的随机分布,通过计算这两个随机分布的相对熵来过滤推荐信息的噪音。
本文提出了基于相对熵的推荐信息过滤方法。相对熵[13]常被用以衡量两个随机分布的差距。两个概率分布p(x)和q(x)的相对熵定义为:
该定义中约定0 log(0/q)=0,p log(p/0)=∞。
若p是节点A与节点B直接交互结果的随机分布,q是节点A的推荐节点X与节点B的直接交互结果的随机分布,根据前面所述节点的二进制等级评价方法,那么p,q都是Ω={0,1}上的两个随机分布,设p(0)=1-r,p(1)=r,r为节点A与节点B历史交互成功的概率;q(0)=1-s,q(1)=s,s为推荐节点X与节点B历史交互成功的概率。于是p,q的相对熵如下:
由式(3)和式(4)可知,如果s=1或s=0,那么D(p||q)=∞。也就是说,推荐节点X所推荐的信息全真或全假,就丢弃这些推荐信息。因为在现有的分布式网络环境下,这两种情况是不大可能存在的,除非节点间始终共谋Ballot Stuffing或Bad Mouthing。
据此计算节点A的每个推荐节点X与节点B的推荐等级评价分布以及节点A与节点B的直接交互等级评价分布的相对熵,当D(p||q)≤ε(ε为距离阈值,本文设其为1)认为推荐节点提供的信息可靠,否则不可靠,这样在进行聚集推荐信息时,就丢弃不可靠的推荐信息。
根据上述过滤方法来更新式(2)中的N1和N0的值:
式中,N1(A→xB)和N0(A→xB)分别是满足过滤条件的“1”的数量和“0”的数量。
节点A计算节点B的信任时,应该考虑历史信任值,而随着时间的推移历史信任也会衰减,因此在t时刻节点A对节点B的信任:
式中,t0为节点A与节点B最近一次交互时间,λ为衰减因子(本文设定λ=2)。
由式(4)可知,当两个随机分布相同时,其相对熵为0。当两个随机分布的差别增加时,其相对熵也增加。
2.4 性能分析测度
我们将使用信任计算错误来评价仿真系统的性能。信任计算错误(即信任计算的标准差),即系统中所有节点计算出的信任值与节点实际的行为之间的平方根。该测度可以定量评价恶意节点对系统性能的影响,同时也用于比较不同推荐信息过滤方法的性能,该值越低,过滤方法的性能就越好。在这部分仿真中,我们主要针对本文提出的方法和文献[14]提出的基于熵的过滤以及文献[8]提出的Beta等级评价系统BRS(Beta Rating System)不真实等级评价过滤进行比较。图5给出了在诚实等级评价者占大多数的情况下三种过滤方法在过滤时间段内的信誉计算错误值。从该图可知,由本文提出的方法所得出的信誉计算错误最低,其次是基于熵的方法,效果比较差的是BRS方法。但是,在6000ticks前,BRS方法优于基于熵的方法。但是,随着时间的推移,基于熵的方法和BRS方法性能趋于接近。
3 结论
本文提出了层次化的分布式信任管理结构。该结构包含应用环境层、统一信任管理层、服务支撑层和通信管理层四个层次,并对每个层次的功能进行了描述。在开放多代理仿真平台Re Past上,重点实现了统一信任管理层的功能模块,在统一信任管理层中实现了基于相对熵推荐信任的过滤方法,同时与基于熵的不真实等级评价信息过滤方法和基于Beta等级评价系统的不真实等级评价信息过滤方法进行性能比较。通过仿真实现,可以发现本文所提出的信任管理体系结构能够很好地嵌入到各种分布式应用环境中,同时本文提出的基于相对熵的不真实等级评价信息过滤方法有很好的性能。
分布式知识体系 篇2
提出了一个通用的分布式GIS的分层体系结构模型:用户界面层、应用层、应用接口层和数据服务层,给出了该模型的`思想和主要特征,并结合Internet/ Intranet环境讨论了模型的实现方法.分层分布式GIS模型的提出可以部分地解决现有的Internet/Intranet GIS存在的问题.
作 者：边学工 胡瑞敏 喻占武 李德仁 BIAN Xuegong HU Ruimin YU Zhanwu LI Deren 作者单位：边学工,胡瑞敏,喻占武,BIAN Xuegong,HU Ruimin,YU Zhanwu(武汉测绘科技大学多媒体网络通信工程研究所,武汉市珞喻路129号,430079)
李德仁,LI Deren(武汉测绘科技大学校长办公室,武汉市珞喻路129号,430079)
刊 名：武汉测绘科技大学学报 ISTIC EI PKU英文刊名：JOURNAL OF WUHAN TECHNICAL UNIVERSITY OF SURVEYING AND MAPPING 年，卷(期)： 25(5) 分类号：P208 关键词：分布式GIS Internet/Intranet GIS 软件体系结构 分层模型
分布式知识体系 篇3
体系结构是网络管理系统的基础, 决定了网络管理系统的框架结构。本模型采用管理站分层、管理任务分布的网络管理体系结构。如图1所示, 体系结构的最底层为管理域, 里面包含若干被管节点, 每个管理域由一个域管理者进行管理;域管理者的管理者为管理站。
管理站分层结构采用由上到下逐步细化的方式分割管理应用。管理系统按照物理 (地理位置等) 或逻辑因素 (部门或管理功能等) 将管理站划分层次, 对管理应用逐层分隔成不同粒度的管理任务, 上层管理站在把管理任务委托给下层管理站之后, 由下层管理站独立完成, 只将执行结果上传。上层管理站具有更多的全局性知识, 处理更复杂的网络事件, 而下层管理站处理相对简单的网络事件, 下层管理站处理的事件是上层管理站处理的事件的子集。顶层管理站支持各种网络管理功能, 提供相应的管理应用, 并且为管理员提供良好的图形用户接口。系统可以有多个顶层管理站, 以提高系统的容错能力, 或者各个系统实现不同的网络管理功能, 以便均衡负载, 提高管理效率。中间层管理站具有双重角色:它是下层对象的管理者和上层管理者的代理。中间层管理站的层次和数量可以动态地增加和删除, 以适应不同的网络规模或者满足不同的管理应用的需要。管理站分层结构的优点是适应网络层次化的特点, 不同层次管理站的管理功能较为独立, 同层管理站之间没有相互通信, 它们之间的协调是通过上层管理站完成的。
管理任务分布结构是指域管理者将管理任务委托给管理域中的代理, 在代理本地对管理对象进行实际的管理操作。我们采用移动代码技术实现管理任务的委托。管理任务委托方式提供细粒度的版本, 域管理者能够通过加强管理策略来控制代理的行为。代理作为管理域的组成元素, 一方面为管理任务提供执行环境, 另一方面根据管理任务的要求收集和提供网络对象的管理信息。
图2描述了本模型下网络管理系统的软件层次结构。最顶层为管理应用, 分为五个功能域, 分别是配置管理、性能管理、故障管理、安全管理和计费管理;每个管理应用包括若干分布式管理应用组件, 并为用户提供了应用配置接口, 另外, 在这一层还为用户提供了定制任务及策略的公共接口, 为整个管理系统所服务;管理应用被管理站逐层分隔成通用管理服务, 即管理任务;管理任务调用其下层的分布处理服务, 以便在管理域中的每个代理端分布运行;管理任务的通信模型建立在分布对象服务所提供的方法上, 而后分派到代理端, 通过与代理进行交互从而获取管理对象的信息或对其实施管理操作。
2 模型结构
模型的核心部分是域管理者, 它承担了承上启下的作用, 一方面需要完成管理站所指定的管理应用 (如图3所示) , 另一方面需要将管理应用划分成若干管理任务, 分布到被管节点中执行 (如图4所示) 。
域管理者主要由三个组件构成:
(1) 任务处理器:负责接收管理站的任务调度, 将管理任务分派到管理域中, 而后将执行结果返回给管理站;
(2) 事件处理器:负责接收管理任务发出的事件, 并对事件进行过滤和关联;
(3) 策略处理器:负责接收来自事件处理器的事件关联结果, 以确定按照何种策略为被管节点扩展管理任务。对于无法在本地处理的故障, 上报至管理站。
在本模型中, 为了简化管理站的设计并相应减少管理站间通信的复杂性, 位于不同层次的管理站采用相同结构。
管理站主要由四个模块组成:
(1) 故障报告接收器:负责接收来自下层实体 (下层管理站或域管理者) 的故障报告, 该类报告是经过域管理站关联后的结果;
(2) 策略处理器:负责对事件采取相应行为;
(3) 事件分发器:负责将事件分发至三个流向, 即上层管理站、管理员或者管理应用;
(4) 管理站还有一个专门解析管理指令的指令解析器, 一方面将管理应用发出的管理指令解析成管理任务所识别的任务调度指令, 另一方面将管理任务的返回结果解析成管理应用所识别的信息格式。
域管理者和被管节点之间的通信由如下三个过程组成:
(1) 域管理者采用移动代码技术实现管理任务在被管节点的分布。采用基于移动代理的方法获取实时数据, 采用基于远程计算的方法获取非实时数据;
(2) 当管理任务发现管理对象的状态发生异常或性能超过预定指标时, 以消息传递的方式向域管理者发送事件报告;
(3) 为了提高系统扩展的灵活性, 每当网络的管理需要发生变化而要改变代理的功能或者由于MIB定义新的事件而被修改时, 被管节点可以通过按需代码方式从域管理者的代码库中下载有关程序, 实现自动更新。
被管节点主要由两个组件构成:
(1) 任务执行环境:负责接收管理任务, 并且提供一个能够与系统Agent进行交互的平台;
(2) 系统Agent:为了减少管理任务自身的体积, 在被管节点中将MIB的实现以及低级的网管操作独立出来, 由一个系统Agent来实现。
3 结语
在大规模分布式网络管理中, 网络资源的数目繁多且异构性强, 基于域的管理结构存在若干管理者, 如果管理任务的配置等工作仍然基于“管理员密集”模式, 则管理员的工作负荷将大大增加, 由此所引起的管理低效和高出错率不能满足网络管理的要求。本文就该问题提出了一个分布式网络自管理模型, 围绕以下几点展开了研究:
(1) 提出该模型下被管节点、管理站、管理域、域管理者、管理任务和事件的概念;
(2) 提出一个管理站分层、管理任务分布的网络管理体系结构。对管理站、域管理者和代理三个管理实体进行了对比。提出了管理系统的软件层次结构;
(3) 描述了网络自管理模型的结构和各模块功能;
(4) 描述了管理站—域管理者、域管理者—被管节点的通信机制。
参考文献
[1]郭楠, 赵宏.基于Web的分层式网络管理系统的设计与实现[D].沈阳:东北大学, 2001.
[2]王平, 赵宏.分布式网络管理系统体系结构和管理机制的研究[D].沈阳:东北大学, 2002.
[3]徐斌, 钱德沛, 张文杰.主动网络管理体系结构的研究[J].计算机研究与发展, 2002, 39 (4) :488-494.
室内分布监理基础知识 篇4
四、简答题
1、监理员的工作职责有哪些？
答：
A、检查承包单位投入工程项目的人力、材料、主要设备及其使用、运行状况，并做好检查记录；
B、复核或从施工现场直接获取工程计量的有关数据并签署原始凭证；
C、按设计图及有关标准，对承包单位的工艺过程或施工工序进行检查和记录；
2、监理实施细则应包括的具体内容有哪些？
答：A、专业工程的特点；
B、监理工作的流程；
C、监理工作的控制要点及目标值；
D、监理工作的方法及措施。
五、案例分析
1、某一室内覆盖工程设计文件已通过相关单位组织参与会审，计划开工日期为11月1日，完工日期为11月25日。在监理组织的开工交底时发现第4层的美食城并未按原定方案装修开业，业主确认该层已改为仓库，可以不做覆盖。在设备、材料的检验过程中发现厂家提供的馈线及双频全向天线规格、型号与设计文件中的不符，在工程施工进行到第20天时，发现完成的工程量只达一半，部分已完工程工艺存在严重问题，在结算审核时发现施工单位报的工程量与设计文件完全一样。请问如果你作为主管该工程监理项目经理或单项负责人你如何处理上述问题？
答：
1、业主确认美食城该层已改为仓库，可以不做覆盖，建设方、监理方、设计方、施工方（厂家）四方项目负责人应在现场确认后，按照工程设计变更流程办理设计变更手续；
2、材料不符合要求，监理人员应向施工方（厂家）发监理工作联系函，要求施工方（厂家）及时更换，现场监理人员在场点验；
3、时间早已过半，事实上只完成工程总量的一半，进度不符合要求，由施工方（厂家）向监理方发《延长工期报审表》提出工期延长的理由和完工的时间，由监理人员审核，报建设方批复；
4、部分完工的工程工艺有问题，现场监理人员应向施工方（厂家）发整改通知单，限时按验收标准进行整改后，监理人员现场验收；