利用FAB原理军事拼装模型模型给客户带来什么样的价值

00/27e66c8a-410a-c206d5c892复旦大学
硕士学位论文
一个基于Java的网络计算模型
姓名:周志荣
申请学位级别:硕士
专业:计算机应用
指导教师:张世永
本文从充分利用空闲计算机计算能力的角度出发,分析了网络计算的现状和
促进网络计算发展的一些因素。指出了基于Java的网络计算具有最小执行环境
小,安全性强,管理集中,性价比高等优点,是具有广阔前景的网络计算模式。
然后,本文重点提出了自己设计的一个基于Java的网络计算模型,它以面向对
象的设计方法为基础,EJB技术为依托,抽象出了任务提交节点,管理节点和计
算节点三种对象类型,详细定义了它们之间交互的接口,状态转换和具体数据结
构细节并对每个部分进行了详尽地分析。接下来,本文讨论了一些具体实现时遇
到的问题和相应的解决方法。为了在实际问题中验证此模型的实用性和可行性,
本文提出了一个破解RSA算法的实例,它能很好的运用本模型提供的管理功能,
实现了高度并行化地破薜:然屠:本文对整个模型的设计进行了一个回顾和总结,
对有待发展的方面进行了分析并提出可能的解决办法。最后,本文对基于Java
的网络计算的美好前景做了展望。
关键词:J打j、网络计算、EJB
Inthispaper,wefocusonthekeytechnologyinusingtheidlecomputer’Scomputingpower.
Afterananalysisofthecurrentprojectworldwideonnetworkcomputingandtheadvantagesfor
networkcomputing,wepoimouthatthenetworkcomputingbasedonJavatechnologyisavery
promisingmodel,whichhastheminimalruntimeenvironment,strongsecuritymechanism,
centralizedmanagementandgoodperformance-pricerateThenweproposeanetwork—computing
modelbasedonJavatechnology.Thismodeldoesuseobjectorienteddesignmethodandabstract
threeobjects:problem—proposedsite,managementsiteandcomputings te.Thismodela so
definestheinterfacesbetweentheobjects,statech ngesinthemandthedetaildatastructures.The
EJBarchitectureisintroducedinmanagementsitedesign.Afterthat,Wediscusstheproblems
encountereddu ingtheimplementationandthemethodstosolvethemareputforwardtoo.To
provethefeasibilityandpracticepracticality,arealcaseofhackingRSAarithmeticus ngthis
modeliSgivenwithexplanation,ThismodeIshowsitselfagoodchoiceforsuchkindof
massive-tryingproblems.Atlast,wemakeafullviewofthismodelandtakeafuturesighintoit.
KeyWords:Java,NetworkCompu ing,EJB
●二尘苎王!些!塑旦塑生兰夔型 一第一章序言
1.1网络计算的背景
“计算”这个词对人类来讲有着特殊的意义,人们生活中经常在进行着各种各样大大
小小的“计算”,而“计算”在不同的时代有不同的内涵:
●手工计算时代
远古时,“计算”只是实物交换的计数,直到100年前,提起“计算”,依然使人联
想到大量烦杂的手工计算。
●机器计算时代
一九四六年第一台电子计算机ENIAC问世,人类进入了计算机时代,摩尔定律说
明每十年计算机系统性能会增加100倍,而每一次计算能力的重大进步都会对人类的
实践活动带来革命性影响。然而需求同时也在和计算机能力在进行赛跑,我们需要越
来越强大的计算能力。
●网络计算时代
几乎在发明计算机的同时,人类还发明了计算机网络,发明了今天的Intemet,进
入了网络时代。在今天的网络计算时代,“计算”已经有了最广泛的含义,网络将可
看作是最强有力的超级计算环境,包含广泛的计算、数据、存储、设备和仪器等资源,
网络计算将包括科学计算、移动计算、多媒体、事务交易处理、电子商务、管理、模
拟、控制等分布式协同计算和智能处理等等。
无处不在的计算机网络正在或将要彻底改变人类的生活方式,把人类带向空前灿烂的
2l世纪一网络世纪。以网络为主体的“计算”革命才刚刚开始,人类将进入2l世纪的网络
计算时代。
1.2网络计算的基本概念
网络计算平台是高速网络互连一组工作站或PC机群组成的并行计算机;或组织网上分
散的空闲处理机组成虚拟的并行工作组;或利用网络上已有的各类资源(包括计算机、数据
源、仪器等)形成高性能的协同计算工作环境,用来解决天气预报、地震分析、化学工业、
材料科学、生物科学、环境研究、结构分析和仿真等许多领域内中、大粒度的复杂计算问题,
以及被称之为“巨大挑战”或“国家挑战”的大型计算问题。这类技术应用越来越广泛,正
逐渐取代昂贵的传统并行计算机。应用还包括:
●事务处理:在线事务处理(OLTP)如电子商务、证券交易等和在线分析处(OLAP)。
●并行数据库:支持Oracle、DB2等分布式数据库应用的数据库服务器。
●分布式处理:异构、多类资源的协同计算处理。
● 网络服务器:运行各种Intemet服务。
二尘茎±!竺!塑塑竺盐竺塑型一——
一个简单的非精确性定义为:网络并行计算系统由~组互联的同构或异构计算单元和相
关资源组成,被用户视为单~的计算环境。
1.3网络计算系统的计算模式
应该看到,现行的网络架构并不是为并行计算而设计的,其目标只是为了网络用户能进
行某些通信和交互。从网络高性能计算的目标和要求来看,其软件系统更为复杂,为了与现
有软件和网络技术保持兼容,一般不采用从裸机开始的重新设计,而是设计成运行在现有微
内核网络操作系统之上的一个可重用、可扩展的服务和功能集合。形成一个所谓的中间件
(middleware)。现有的网络高性能计算项目和研究都非常庞杂,组建思想和实现形式各异。
按照组建思想和范围,我们可把它们分为技术相关的两大类:
●机群计算(ClusterComputing)
它采用高速网络连接一组工作站或微机组成一个机群(Cluster),或在通用网上寻
找一组空闲处理机形成~个动态的虚拟机群,使之在中间件管理控制下提供具有很高性
价比的高性能计算服务。机群又可分为:专用机群,非专用机群。极高的性能/价格比是
专用机群受到欢迎的特点。
●网格计算(GridComputing)
顾名思义,它的目标是将广域网上一些计算资源、数据源和其它设备等互联,形成
一大的可相互利用、合作的高性能计算网,用户可以象登录一台超巨型机一样使用它。
1.4促进网络高性能计算发展的原因
● 广阔的前景;随着Intemet的迅猛发展,网上已有数千万的各类计算机。包括为数众多
的高性能计算中心,如何更好地扩展和利用网络资源已成为人们日益关注的课题,显然,信
息并不是网上唯一能获得的资源,网上计算机如果能被组织加以协调工作,将会形成有巨大
潜力的并行计算环境,直至形成一能力无比的全球计算环境。
●应用的驱动:实际的网络资源利用率是很低的,据有关统计,系统平均使用率仅为30%
左右,有的空闲率竞达91%,如何利用闲散资源形成相当强大的并行计算能力成为一个重
要研究方向。
●单个的PC变得越来越功能强大,也就是说,PC机的性能在过去几年中迅速增长,每
18.24个月就增长一倍,随着更快的处理器、效率更高的多处理器计算机将进入市场,未来
几年内这种趋势还将继续下去。此外,PC机还被广大的用户熟悉和使用。
●网络技术的突破:通信带宽在增长,延迟在降低,这归功于新的网络技术和协议的使用。
Tbps级传输速率和超低传输差错率将成为现实,网络的带宽局限将得到极大缓解,安全性
大大增加,网络的瓶颈将从“低速传输”转移到“高速传输、低速管理软件”上。
●网络高性能计算具有独特的优势:可扩展性强,计算资源几乎可方便地任意扩展;可靠
性高,已存在大量成熟的网络技术和开发工具,许多公用程序已逐渐标准化。
二尘苎王!竺!箜堕竺笪!堡型一. 1.5网络计算的项目和商业应用●GlobUS项目:
晟著名的发展网格计算的基本软件和工具的项目,对网格计算的理论和实践应用起着重
要的推进作用.其核心是Globus元计算工具包(GMT),这是一个构筑网格计算环境的中间
件,提供基本的资源定位、管理、通信和安全等服务的工具包。并且GMT是模块化的,允
许用户按自己的需要定制环境。
●Beowulf系统:
目前Beowulf在机群系统中具有非常重要的影响。它是基于PC类机器的软件,可以把
在LINUX操作系统下的工作站组织起来形成机群系统。
NOW是Berkeley大学推出的科研软件包,它支持使用多台网络工作站(networkof
workstations(NOW))组成分布式超级计算机,它的根本思想在于利用大量的工作站和高速
网络来完成运行在工作站上的传统串行任务和大型并行编程任务。它提出由100个处理器
组成的系统来处理并行任务,其能力将超过大型并行处理机的性能,而且对串行任务的处理
能力也将高于独立的工作站。它的研究重点在于对操作系统和通信体系结构的研究,并涉及
到网络接口硬件、分布时序安排和任务控制等方面
●DQS系统:
DQS是一个实验性的基于UNIX的排队系统,它由Florida州立大学的超级计算机研究
协会开发。DQS设计一个管理池来帮助从网络上合理分配计算资源。对于异构环境中的所
有使用者和管理者来说,整个DQS的体系结构是完全透明的。
●Legion系统:
基于对象的元计算系统,高速网连接大量的对象,支持透明的调度、数据管理、容错和
安全操作。
●基于Java的网络计算Javalin项目
弗吉尼亚大学计算机科学系前些年在Java语言和相关技术成功地解决了困扰网络计算
的几个关键问题,如异构性和安全性后,对基于Java的网络计算进行的研究项目。
●GridEngine服务器软件:
Sun公司2000年末发布了免费的GridEngine服务器软件,该软件能使计算密集型作业
(如仿真作业)在网络中的数百颗空闲处理器上运行。GridEngine有一个负载均衡算法,
能将作业分配给可用的处理器,而且可以根据优先权排队等候作业请求。GridEngine可以
用于所有Sun工作站。
● CancerR search:
NationalFoundationforCa cerR search(NFCR)和UniversityofOxford发起的利用你的
计算机空余时间进行的旨在发现治愈癌症的药物基因分子的筛拣,为了更早地找到能够防止
癌症的药物,该计划已经制作了全球电脑共同参与的程序。
第二章网络计算现状的分析
2.1机群计算(ClusterComputing)
2.1.1基本体系结构
机群系统是互相连接的多个独立计算机的集合,这些计算机可以是单机或多处理器系统
(PC,工作站或SMP),每个结点都有自己的存储器,I,o设备和操作系统。机群对用户和
应用来讲是一个单~的系统,这样的系统可以提供低价高效的高性能环境来提供快速可靠的
服务,其一般结构如图1。
机群系统一般包括下列组件
● 高性能的计算结点机(PC,工作站或SMPS)
· 具有较强网络功能的微内核操作系统
● 高效网络,交换机(如干兆以太网)
● 网卡(NICs)
● 快速传输协议和服务。
● 中间件层,包括:
~某些支持硬件(如数字存储通道,硬件分布共享存储器及SMP技术)
~应用(如系统管理工具和电子表格)
~运行时系统(如软件分布共享存储器和并行文件系统)
~资源管理和调度软件等
· 并行程序设计环境与工具,如编译器、语言环境,如并行虚拟机(PVM)和消息传递接
口(MPI)等。
·应用: 包括串行和并行应用程序。
2.1.2性能及实用性分析
·专用机群
专用机群一般由一组同构的处理机组成,通常安装在一个机房内,由系统管理员统一管
理,用户可通过前端机进行访问,用户无需知道机群的详情,就像使用MPP机一样,这种
机群易于配置、易于管理,不受外界干扰,通讯可靠延迟小,适合于面向加速比的并行任务
和面向吞吐量的批处理作业。专用机群具有相对结构和管理简单,易于扩展等特点,用途极
广。和大型并行计算机相比,机群系统具有很高的性价比,但从基本体系结构的分析很明显
地就可以看出机群计算仍需要有较强网络功能的操作系统支持,需要设计精良,结构复杂的
机群中间件来支持,就是其绝对成本(软件和硬件)来说也是比较昂贵的。同时,其扩展的
极限也受到网络构架,机群中间件管理能力的限制而不可能超越一定的数量级。
·非专用机群
非专用机群主要思想是由分散互联的处理机或在网上寻找的空闲处理机组成韵机群,这
些处理机可能分属于不同的个人、组织或单位。据资料统计,一般计算机系统平均使用率仅
为30%左右,有的空闲率竟达91%,而许多桌面网络工作站和微机的CPU利用率都小于10
%,因此。自然想到要利用这些闲散的CPU处理能力,这也称之为CPU周期窃取。通常,
网络上计算单元都有其拥有者,并且各个拥有者孤立地使用其拥有的计算单元,一般这些计
算单元在做下列类典型的工作:
●正处于空闲或等待状态,如夜间。
·文档编辑工作,包括接、发Email,阅读文档和信息等。
·开发工作,包括编辑、编程、编译、调试等。
●完成某种定时、守候服务和功能。
·运行计算型的程序。
所谓窃取CPU周期就是要窃取上述前四类处理机的CPU周期给最后一类程序用,非专用
机群地理上分布于不同的所有者,由异构系统组成,大部分是通过以太网连接,适用于企业
级局域网范围,技术难度要高于专用机群,工作站主人和需要工作站运行程序的远程用户之
间存在矛盾,前者希望和工作站快速交互,而后者只关心能否利用所有共享CPU来快速运
行程序,所有者必须具有参加机群的动机,这意味着参加者相信贡献他们的资源是有意义的。
但是,这些所有者不希望在他们工作时,或他们的系统过于饱和时,受到其它干扰,一个策
略是允许所有者退出机群,国际上正在形成一种计算资源的买卖市场,以刺激资源拥有者加
入网上机群。此外,由于当前网络通讯速度和质量瓶颈及由通讯竞争造成的网络不确定性的
存在,对非专用机群技术有更高的要求,如对进程迁移、负载平衡等技术的需求。但此类系
统最为贴近普通用户,可以充分利用网上无穷无尽的资源,而组建投资几乎可忽略不计,这
也是非专用机群所具有的最大有点,本文提出的基于Java的网络计算模型也部分借鉴了它
的优越性。
二尘苎王!竺!堕堕竺生苎堕型——
2.2网格计算IGridComputing)
2.2.1基本体系结构
“网格计算”是通过网络连接地理上分布的各类计算机(包括机群),数据库,各类设
备和存储设备等,来形成对用户相对透明的虚拟的高性能计算环境,应用包括了分布式计算、
高吞吐量计算、协同工程和数据查询等诸多功能。网格计算被定义为一个广域范围的“无缝
的集成和协同计算环境”。网格计算模式已经发展为连接和统一各类不同远程资源的一种基
础结构。为实现网格计算的目标,必须重点解决三个问题:
●异构性:由于网格由分布在广域网上不同管理域各种计算资源组成,怎样实现异构
机器间的合作和转换是首要问题。
●可扩展性:要使网格资源规模不断扩大,应用不断增长情况下,不降低性能。
●动态自适应:在网格计算中,某~资源出现故障或失败的可能性较高,资源管理必
须能动态监视和管理网格资源,以便及时地从可利用资源中选取一个后备资源。
网格计算环境的构建层次从下往上依次是
●网格结点:由分布在Internet上的各类资源组成,包括:各类主机、工作站甚至Pc,
它们是异构的,可运行在UNIX、NT等各种操作系统下;也可以是上述机型的机群系
统、大型存储设备、数据库或其它设备。
●中间件:是网格计算的核心,负责提供远程进程管理、资源分配、存储访问、登录
和认证、安全性和服务质量(QoS)等。
●开发环境和工具层;提供用户二次开发环境和工具以便更好利用网格资源。
●应用层:提供系统能接受的语言,如HPc++和MPI等。可配置其它一些支持工程应
用、数据库访问的软件。还可提供Web服务接口,使用户可以使用Web方式提交其作
业并取得计算结果。
2.2.2性能及实用性分析
网格计算环境要求不影响各结点本地的管理和自主性,不改变原有的操作系统、网络协
议和服务,保证用户和远程结点的安全性,允许远程结点选择加入或退出系统,尽量使用己
存在的标准的技术以便和已有应用兼容,并能提供可靠的容错机制。一个理想的网格计算应
类似当前的Web服务,可以构建在当前所有硬件和软件平台上,给用户提供完全透明的计
算环境。对用户而言,它把众多同异构的资源变成了同构的虚拟计算环境。为此,网格计算
环境设计需要有以下的特征:
●管理层次:确定的管理层次体系,管理按区域层次划分。
●通讯服务:随应用目的不同提供不同的服务,包括可靠的点对点和不可靠的组播通
讯,支持各种通讯协议,提供通讯链路延迟、带宽和可靠性等指标。
●信息服务:提供方便可靠的机制获得不断变化的各结点的信息和状态。
●名字服务:提供全局统一的名字服务,典型的有国际通用的x.50标准或Intemet上
●文件系统:需提供一个分布式文件系统机制,全局存储和缓存空间。
二尘茎±!!竺塑旦塑生竺堕型——
●安全认证:应包括登录认证、可信赖、完整性和记帐等方面的安全,安全性是网格
计算的难点,也是系统成败的关键。
●监视系统:提供监视系统资源和运行情况的工具。
●资源管理和调度:提供透明资源调度,高效的利用可利用的资源是系统的核心。
●资源交易机制:为鼓励不同组织或资源拥有者加入系统,应提供一种计算资源的交
易机制,允许提供资源者获得利益,使系统能动态地取得最好的性价比资源。
●编程工具:必需提供丰富的用户接I=1和编程环境,提供最常用的语言,如C,c++,
Fortran,MPI、PVM以及分布式共享存储器和一些函数库等。
●用户图形界面:提供直观的用户访问接口,包括Web方式,使用户可以在任何位置、
任何平台上使用系统资源。
由此可见.网格计算比机群计算更复杂,要成功高效地建立一个网格计算模式并不是件
容易的事情,很多研究项目正在进行这方面的开发和研究,也有一些研究成果,但一个完整
的网格计算必须做到上述几个方面,从而导致了系统过于复杂,庞大,而且各自项目的结构
和实现并不统一,大规模的应用并没有成为现实。
2.3基于Java的网络计算
2.3.1研究背景
为了实现平台无关性,Sun公司在90年代中期推出了Java语言,其终极目的就是程序
代码只要一次性编写,就可以在所有的平台上无须修改地运行。这种“天生”的优良品质给
网络计算的实现带来一种新的可能。接下来的几年中,Java语言及其相关技术的发展,成功
地解决了困扰网络计算的几个关键问题,如异构性和安全性。同时随着Intemet的飞速发展,
越来越多的Web浏览器可以支持Java程序在其中运行,它的最小执行环境已经缩小到一个
简单的Web浏览器而不需要另外安装软件,因此,理论上全球任意一台装有Web浏览器的
机器都可以参与全球计算。尽管那时的Java平台还存在效率低等问题,但它仍然大大地影
响了一下网络计算模式的发展,实现全球分布式计算似乎已不再是一个梦想。这时,基于
Java的网络计算项目中最著名的“Javalin”诞生了,它是构建立在Internet网络层上,通过
扩展HTTPServer的功能来实现的,其基本实现方法如下:
●问题提交结点向HTTP服务器上载包含有任务Applet的HTML主页:
●问题提交结点向集中管理服务器登记相应的访问此任务Applet的URL地址
●计算结点向集中服务器请求任务,得到相应任务的URL;
●计算结点从HTTP服务器下载HTML页,运行其中嵌入的Appleh
●问题提交结点得到回送的执行结果。
可以看出,Javalin项目只是早期对基于Java的网络计算的一个初步尝试,这是因为当
时Java语言主要是用于编写网页内嵌的小程序,本身并没有为大规模企业级应用做好准备,
对状态维护,事务处理等都没有提供支持,实现复杂的大型网络计算模型是不可能的,所以
Javalin项目并没有得到很大的发展。但是Javalin项目充分展示了基于Java的网络计算的可
行性和广阔前景,这正是Javalin项目作为探索者所做出的贡献。
■一个基于Java的网络计算模型
随着Sun公司不断地对Java进行完善和改进,现在,Java已经从最初的一种简单的解释
执行语言发展成为一整套应用解决方案。特别是Java2EnterpriseEdition规范的推出,使得
Java在企业级关键应用中可以大展身手,并且由于Java与生俱来的可移植性和开放性,一
时间基于Java的企业级应用如雨后春笋般涌现,这又同时反过来促进着Java本身的完善和
发展。可以说现在的Java和几年前的Java已经是不可同日而语了,不论在速度,安全,灵
活性,事务处理方面都有了长足的进步。这一切无疑也给基于Java的网络计算带来了新的
生机和发展空间。本文也就是在这个环境背景下提出了一个新的基于Java的网络计算模型,
它借鉴了Javalin项目的计算模式,充分利用了已经发展了的Java技术和特点,避开实现完
整的复杂的网络计算模型,抓住一大类可并行性相当大,探索性求解的问题,设计简洁,但
更具有实用性。
2.3.2发展前景和意义
正如前言中1.4中所介绍的那样,网络计算随着现有技术的发展而不断的发展,但是
它所不能避免的计算结点之间的通信,协调也越来越复杂,这很大程度上是为了实现对客户
端的透明,而很多时候需要解决的问题可并行性很大,并不需要复杂的协调,客户只要适当
地定制~下就行了。在这个时候使用庞大,复杂的网络计算系统就不是很合适,况且获得这
种环境也不是容易的事情。这时,一种简单易行而且安全的系统将是更好的选择。基于Java
的网络计算正是符合条件的最佳候选人,它具有以下几个不可比拟的优点:
●最小执行环境小(Java的一个虚拟机),可扩展性和实用性极强:从目前来看,它可
以是一个可以运行小程序的浏览器,一个可上网的PDA,一个智能的移动设备(如手机),
一个家庭信息终端(如现在如火如茶的信息家电)等。
●安全性强:各个参加运行的结点可以毫无忧虑地参加计算,因为Java小程序的安全
机制确保了它不会侵害运行小程序的载体。比起要下载程序在本地运行的方法来说要安
全的多,以本地程序方式运行可以作任何想做的事情,谁能保证程序不出错或者不受到
恶意攻击者的欺骗?
●管理集中,可维护性和容错性好:由于~般由一个控制结点管,易于管理,而且计
算结点的参与和出错将不影响问题的解决。
●性价比高:它不需要什么特殊的设备和繁杂的中间件设计,方便实用。
所有这一切都展示着基于Java的网络计算的美好前景。随着Java技术本身的不断发展
和完善,它的优越性将更加明显。而且由于它是基于Internct网络的,而Intemet的迅速发
展也是有目共睹的·而且无线网络的加入更加展现了它广泛的伸展空间。在这时提出~个实
用的模型将是~个有益的尝试,虽然它不可能做到面面俱到,但是至少是把基于Jaya的网
络计算的实用性和可行性展示给了大家。
二尘苎±!型!盟堕竺笪苎堡型 一——
第三章一个基于Java的网络计算模型
3.1总体构架
本模型的基本思想是对问题的分解和状态进行统一的管理,各个参与结点只是简单的
通过Intemet获得计算代码参加计算,这样做是为了充分利用各个结点的计算能力,减少了
和管理结点之间的协调,削弱了对计算结点的限制,使得理论上任何具有计算能力的设备都
可以参加计算,从而使本模型有更广泛的应用空间,这也是以Java为基础而带来的可能。
整个构架抽象为三个部分组成:问题提交结点,管理结点和计算结点,其中管理结点中包含
有WWW服务器和EJB服务器两个部分。结点间通信是基于设计好的Java语言的接口
(Interface),使设计符合面向对象的设计方法,利用Java语言的多态性来对不同的问题进
行不同的实现。整个构架框图如下:
3.1.1问题提交结点
它是问题的提出者,当一个问题的解可并行性相当大(如生物化学中基因分子的筛拣)
或者是一个探索型求解问题(如依靠庞大的字典来进行密码破译)时,它就可以考虑使用本
模型来解决问题。提交问题的过程是通过本模型定义好的接口Requester来进行交互的,解
决问题过程中通过Dissolver接口来进行问题的分解。当问题全部解决后通过一定的消息机
制(比如电子邮件)通知问题提交者,问题提交者通过访问管理结点取回结果。
一个基于Java的网络计算模型
3·1·2管理结点:
它是管理问题的分解和派发的关键,它作为一个桥梁沟通了问题提交结点和计算结点t
作为中间人它使得计算结点无须知道在为哪个问题提交结点服务,同时也使问题结点提交问
题后就无须再过问,做到双方面的透明。它和问题提交结点的交互是通过本模型定义好的接
13Requester实现,它和计算结点的交互通过本模型定义好的类Computer实现,需要指出的
是Computer类是基于小程序(Applet)的,它是下载到计算结点运行的。在问题的解决过
程中通过Result接13管理各个子问题的计算结果和整个结果的状态。问题整体的解决是由
EJB服务器的请求队列管理模块,问题分解模块,问题状态管理模块三个重要模块共同实现
的。管理结点还负责生成和保存一个问题名字到问题ID映射的列表,在EJB服务器中都是
以问题ID为关键字,在管理结点设计中有详细的说明。
3.1.3计算结点
计算结点是任何可以通过Intemet访问管理结点并具有计算能力的设备,它通过管理结
点获得一个计算任务,其形式是本模型定义好的类Computer,由计算任务自身自动地和管
理结点进行交互,自动地将执行结果通过Result接口返回给管理结点。
3.2详细设计
本节主要讨论各个接口和结点之间具体的交互过程,对本模型做一个详细的阐述,讨论
是基于模型层的,就像在制定一个规范,具体的编码实现可以是多样的,作者将自己实现过
程中遇到的问题在下一个章节做个简要的介绍。下面将按问题解决的过程逐步讨论。
3.2.1问题提交结点和管理结点之间接口的设计
(1)问题提交接口设计:问题提交结点通过HrrP协议提交一个实现了Requester接13
的程序包,管理结点根据这个程序包提取一定的信息和接口实例。问题提交结点和管理结点
之间的交互是基于HrrrP协议的,因为这是唯一能穿越各种防火墙的协议了,其余各个类型
结点之间的交互也都是基于HTTP的,以后就不再说明了。当管理结点收到问题结点的
Requester包后,如果问提交的时候已经有同样名字的问题解决过了或正在解决中,系统就
认为它们是同样的问题,系统将就直接返回上次的计算结果或者把它的地址和密码加入等待
此问题结果的列表中去(如果相同的E.mail地址已经存在于列表中,系统认为是同一人,
将不再加入)。否则管理结点向EJB服务器的请求队列管理模块提交新任务的加入请求(具体
设计在下一节提tB),管理结点将负责把它完成。下面是本模型中Requester接口的具体定义:
publicinterfaceRequester{
publicStringGetProblemName0;
publicStringGetRequesterEmail0;
publicDissolverGetDissolver0;
publicResultGe Result0;
publicStringGetResultPassword0;
//获得问题的名字
//获得问题提出者的邮件
//获得问题分解实现
//获得问题结果实现
//获得获取结果的密码
一个基于Java的网络计算模型
问题提交者和管理结点之间实现问题提交流程的示意图如下
[ 问题提交者 l
l 1.通过Intemet访问管理结
I 3.返回已经计算过的结果Il点提交一个程序包Requester
如果同样名字的问题已经存在并且结果仍然存在,执行
3,否则管理结点进行问题名字到问题ID的转换,执行2。
1. I 2.把新任务及其ID转给请求管理队列模块|
FOB服务中的请求队列管理
(2)问题结果取回的接口设计:EJB服务中的状态管理模块通过定期的查询计算任务的完成
情况来了解各个任务的完成情况,如果已经完成,则通过一定的方式(现阶段采用E.mail)
来通知问题提交者问题已经解决,这个联系方式是通过用户提交的程序包中Requester接口
的GetRequesterEmail方法来获得的。问题提交结点得到通知后,通过访问管理结点的指
定页面,提交口令(问题提交的时候由提交者确定的,这样作可以实现一定的安全性)和问
题的名字来获取计算结果,结果是以一个实现了Result接口的程序包的形式返回的。提交
结点和管理结点的问题结果取回示意流程图如下:
二尘董王!竺!盟塑塑生竺塑型——
3.2.2管理结点的设计:
管理结点的主要功能是实现问题的分解,请求队列的管理和问题解决状态的管理t它是
整个模型的核心。其首先将要面临的问题是状态维护问题,由于问题的解决是个长期的过程,
问题解决的一些中间状态,中间结果必须记录下来,在这里EJB服务器提供了强大的状态
维护支持,它是管理EJB容器的高端进程或应用程序,并向EJB容器提供对系统服务的访
问。EJB服务器也可以提供厂商自己的特性,如优化的数据库访问接12l,对其他服务(如
CORBA服务)的访问,对SSL3.0的支持等。一个FAB服务器必须提供对可访问JNDI的
名字服务和事务服务的支持。EJB容器是一个管理一个或多个EJB类,实例的抽象。它通过
规范中定义的接口使EJB类访问所需的服务。容器厂商也可以在容器或服务器中提供额外
服务的接口。现在没有EJB服务器和EJB容器间接13的规范。因为目前容器通常由EJB服
务器来提供,所以一旦接I=1标准化了,厂商就可能提供可以在任何兼容的FAB服务器上运
行的容器。值得注意的是EJB类,实例是可以借助EJB服务器和数据库的交互来实现
Persistence的,而Java对象的可序列化(Serializable)规范确保了符合规范的Java对象具有
Persistence的能力,简单的说就是把对象储存起来并在需要的时候读出重建为原来的对象的
能力。下面是一个EJB服务器,EJBContainer和我们的管理结点之间的示意图:
糊精●嘲Y_
/’毫∞ON嘲晰1
/ 蜓孢WWW服/。p
.篓. 1 \、,/
注意这里WWW服务器是负责向各种结点用户提供一个良好的动态界面(如www页
面,WAP页面),它和EJB服务器可以不在同一台机器,并且可以用Java来编程,通过Java
RMI来访问home对象和EJBObject,或用其他语言编程并通过CORBA/IIOP访问,使得部署
的服务器端组件可以通过CORBA接口来访问。同时我们还让www服务器还担当另外一
个重要的任务:维护一个问题名字到问题ID的列表。我们用一个全球独立的数字(GUID)
二全苎主!竺!竺塑竺生差堕型——
来唯一标识一个问题,GUID是在接到新计算任务请求时生成的,关于GUID的生成有很多
种方法,这里就不叙述了。列表的管理比较简单,只是简单的查找,加入t删除,不再赘述。
这样做的目的是为了在以后的运算中都有一个唯一标识。我们可以看到整个管理结点的主体
实际上是位于EJB服务器的中,下面我们将从状态管理模块开始讨论EJB服务器中各个模
块的详细设计。
I.状态管理模块的设计:
问题解决的设计很大一部分是状态之间的转换,各个状态信息也就尤其重要,我们首先
就考察一下一个问题的解决需要哪些状态的转换和信息的维护,这里我们以问题的ID为关
键字,按问题的解决过程来考察:
(1)第一步当然是问题一些描述信息,当问题提交的时候由问题提交方给出,因为提交的时
候是以程序包的形式出现,这些信息是静态的,只要在请求队列管理模块中直接提取出来交
给状态管理模块存储起来,用的时候直接查询就行了。现在我们对于计算任务只有一种静态
计算主体,动态参数域的模式,所以计算包也可以归为描述信息一类,每当有计算结点申请
时,直接下载计算包并从问题分解模块中获得自己的计算域,做到足够的灵活性和高效性,
不用每次生成不同的计算包,但同时这也对可解决问题的类型带来了一定的限制,在问题分
解设计中将详细说明。
(2)然后是问题的分解信息,我们必须记录当前问题分解到哪步了,或者说分解到第几个子
问题了,所以这个必须作为重要的状态存储起来,在这里我们用一个长整形的数来表示,每
次需要再次分解一个问题的时候把这个整数加l作为参数调用分解接IZI中的函数
GetRunnerParameter(详细参考问题分解的设计),以从中获得相应的参数域,如果此问题
已经全部分解完,就把此状态变量置成一个特殊标志,标识它已经全部分解完,不再需要分
解了。我们考虑到分解所得的参数域会不止需要一次,因为计算中间可能出现网络拥塞或者
计算结点中途推出计算,不想继续了,这时必须重新派发参数域,还有为了保证计算的正确
性,我们的设计中还加入了冗余因素,同一次分解会被派发两次,综合下来,我们把分解后
所得到的参数域也作为状态存储下来,这样就不用以相同的参数分解两次了。
(3)接下来是问题的结果状态。当问题分解后将分发给请求计算任务的计算结点,由于问题
的解决可能是个比较长时间的过程,管理结点在管理的过程中将不断地接受子问题计算结点
的返回结果,这时要不断的把每个子问题的结果记录下来,并标识相应的标记表示这步计算
已经得到结果。最终当所有的子问题完成或已经找到目标的时候就标志问题的整体解决。并
把中间结果整理得到一个完整的结果存储下来。
有了这三个方面的状态信息,我们已经可以解决问题了,我们将状态管理模块设计作为
EJB服务器中的一个EntityBean,为了灵活性起见,在实现时我们利用了FOB服务器自己定
制了对象成员的存储方法和规则。这个EntityBean将有下面几个成员:
●NowStep,它负责记录当前已经分解了多少步的信息,为长整数。
●NowResult,负责记录当前总体已经解决的程度,通过子问题不断地被解决,它将
被不断修改。最终当所有分解的子问题都解决后它就是所求的结果。实际实现的
时候它是通过Requester接121获得的一个实现了Result接口的实例,由此实例负责
整个结果的管理。具体在计算结果提交的设计中描述。
二尘苎主!竺!塑堕堑盐墨塑型 .——
●ResendQueue,它负责记录那些计算超时后需要重新发送的“NowStep”的整数集
合。实际实现是基于Java的HashSet类。请求控制模块会负责把这些队列中的整
数所对应的参数域重新派发给其他的计算结点重新计算的。
● SolvedMap,它是一个步数到解决状态的映射,反映了某个子问题的结果状态。实
际实现是基于Java的HashMap类。值得注意的是由于每个派发出去的计算任务并
不一定都被正确计算或完成,所以这里的子问题结果状态不只有完成和未完成两
种状态。而且我们设计的时候采取冗余派发的方式,所以我们把状态设为以下几
0:未派发过;
1:派发过一次;
2:派发过两次;
3:派发一次并计算过一次:
4:派发过两次并计算过一次;
5 派发过两次并且计算两次的结果是一样的。
只有状态处在5才我们才认为子问题已经解决,才把相应的结果加入“NowResult”
状态变量中。请求队列控制模块中将有相应的状态机来描述有不同请求加入队列
时5个状态的转换关系。需要说明的是计算过一次的中间结果也是放在此状态中,
用于后第二次计算后的结果进行比较。
●ParameterMap,它是一个步数到参数域的映射。由于上面(2)所述的原因,我们也把
它记录下来,实现是基于Java的HashMap类。
●DispatchTimeMap,它是一个步数到派发时间的映射,反映了某个子问题计算的派
发时间。实际实现是基于Java的HashMap类。它的主要任务是记录两次派发的时
间,用来计算是否超时,关于超时时间的设置可以根据一般网络情况进行调整。
如果没有派发过或需要重新派发这里就设置为0。
● Solved,标志变量,指示当前整个问题已经解决了与否。
(4)关于冗余计算的设计:此模型引入冗余计算的目的就是尽量保证问题计算的准确性,但
是需要指出的是虽然计算结点获取同一个子问题的概率是很小的(发生在是它计算的时候问
题没有继续分解),但也是存在的,这时冗余计算的可以说是不起作用的,因为只不过是同
一个结点计算了两次。况且如果计算结点人为地把小程序运行两遍,你也是没有办法区别它
和另外计算结点的提交(不能用IP地址标记计算结点的方法来区分,因为现在很多连接到
Intemet是通过同一个Proxy出去的,而且局域网虚地址的实用更使大量的结点共享同一个
实地址)。所以冗余计算只不过是一种辅助手段。它并不能保证子问题一定被不同的结点各
计算过一次,只是尽量地实现这个目标而已。
(5)关于超时问题的解决:状态管理模块本身定时检查各个子问题的计算是否超时,它是根
据DispatchTimeMap中的记录来判断,如果超时将把其放入相应的ResendQueue队列,同时
把相应的派发时间设簧为0,其内部状态间转换规则如下:
一个基于Java的网络计算模型
厂一状志。、一\~一/
II.请求队列模块的设计
~/一\\
请求队列模块的主要任务是负责处理新任务的加入,计算结点的计算请求,和状态管理
模块合作挑选参数域提供给计算结点。
首先如果碰到问题提交请求,它将分解出计算包模块(因为是静态的,初始一次就可以
了),然后初始化一些状态信息交给状态管理模块,前面已经讨论过了。
接下来,如果有计算结点申请计算任务,它将根据状态管理模块提供的信息来做如下的
处理:在未解决的问题中选择一个来处理,这里采取的是顺序循环选择的方法,也可以考虑
设置优先级的方法来给一些付费的用户提供更高的优先级。选择好了问题后,从状态管理模
块中提取出相应的状态信息,得到这个问题的当前状态。然后和问题分解模块合作得到相应
的参数域,最后把静态计算包和参数域~起返回给计算结点。
如果有计算结点已经完成子问题的计算任务,提交计算结果时,它将根据当前状态信息
做出相应的反映。从一个状态跨越到另~个状态,直到此子问题的解决。在前面状态管理模
块讨论的基础上,我们提出下面的有限状态自动机,它是针对子问题的解决而提出来的,结
果提交也是针相应子问题的计算结果(具体接口参考下面章节),它是状态管理模块和请求
队列模块之间相互交互和合作的重要部分:
(◇三。乡L飞乡7
,,、.,,,///7 T,,~、、
≯状_二。二: l ,≯:三一。≤
\一I剥i藁函一一少
III.问题分解模块的设计
j |/ 、.
匹堕至匝r-—————————一———]
L兰竺苎苎兰奎!竺J
此模块的设计直接制约着能解决问题的类型,作为初步的尝试,此模块采用静态计算主
体,动态参数域,问题提交者自己根据需要来实现接口的设计思想,以期尽量提高灵活性和
实用性。问题提交者负责提供实现了Dissolver接口的程序包,管理结点从Requester接口中
获得一个实现了Dissolver接口的实例,并借助EJB服务器提供的系统服务以问题lD为关
键字生成基于此Dissolver实例的EJB服务实例,这里生成KIB服务器实例的原因是整个问
题的解决工程可能是漫长的,中间碰到服务器重起,中断等情况,把此接口实例置于EJB
的一个服务实例中可以自动实现接口实例的存储和读取(只要此实例的实现不违背Java对
象序列化的约定),虽然手工自己也能实现,但是利用EJB的服务将更稳定,安全。以后每
次通过接1:3的OetRurmerO方法取得的Computer程序包(它是一个扩展了的小程序包,详
细设计参考3.2.3),GetRunnerParameter(intRunn rlD)方法取得问题的一个参数域。初始时
把相应的状态信息交给状态管理模块保存起来,并且因为计算程序包是静态的,也一并取得
并保存起来以提高效率,它和请求队列管理模块交互生成分解实例的示意流程图如下:
■一个基于Java的网络计算模型
问题提交结点
提交问题 上
管理结点进行问题名字到问题ID的转换
EJB服务中的请求
队列管理模块
结果提交,上 计算请求
‘=\苎刚题堤燹1再登——> 7 羹喜冀霍萎l
EJB服务中的问题分解模块
根据接口函数获得Dissolver
实例生成此EJB实例
工 状态管理模块访问此分解模块获得分解实例
EJB服务中的状态
Dissolver接口的具体定义如下
publicinterfaceDissolver{
publicParameterGetRunnerParameter(intRunnerlD);
publicComputerGetRunnerO;
关于动态参数的问题,因为参数的类型有各种各样的可能,不可能具体指定哪种类型为
参数,所以我们这里只是把它作为一个抽象的定义,它只是一个空的接口类,各个问题的提
交者根据自己的需要定制自己的实现了Parameter接口的扩展类,只要扩展类遵循可序列化
的一些约定,就可以实现类本身的存储和读取,这里之所以要定义一下空接口类,也是为了
使以后扩展保持兼容性。它和管理结点的交互示意流程图如下:
Parameter接口的具体定义如下
publicinterfaceP rameter{)
因为分割问题要由问题提交者自己实现,设计的好坏直接关系到计算的效率和速度,必
须加以足够的重视,本模型提示以下两点注意事项:
A.任务分割的不能太细,也不能太粗,太粗了导致计算时间长,意外中止不能完成计算的
情况越来越多,降低了效率。太细了导致了管理结点和计算结点间的交互频繁,管理结点可
能承受不了。
B.分割问题的时候还要考虑随着问题的深入计算量会越来越大,相同跨度的计算域之间的
计算量可能相差很多。要尽量保持的子问题间的计算量尽量一致,否则将导致后面的计算任
务越来越复杂,计算时间越来越长,意外中止不能完成计算的情况越来越多,超时设计也就
失去了意义。
lv.问题管理的设计
模型中有待解决的问题可能有很多,并且有些问题已经解决了很长时间还没有解决完或
者解决完了很久并没有保留的价值了,这些需要一些管理的界面来提供最基本的一些功能。
其中一个最基本的是任务的删除。因为任务的添加是自动的完成的,而任务的删除有很多人
为的因素,程序很难决定什么时候因该删除整个问题的痕迹。所以需要一个管理界面让管理
员自己来决定。因为这牵涉到具体实现,而且并不需要引进什么数据结构和接口间的交互,
任何实现只要把模型中相关一个问题的所有状态删除掉就可以了。以后系统遇到此ID的问
题,全部回复问题已经删除就可以了。这也是GUID给我们带来的好处,属于同一个GUID
的问题绝对不会干扰另一个GUID的问题。
3.2.3计算结点和管理结点之间接口设计:
I.计算结点计算请求的设计
计算结点的主要任务是请求计算任务,执行计算,返回计算结果。当其向管理结点请求
任务后,它将获得一个计算任务包,其形式是嵌入式小程序(Applet)的一个扩展。计算任
务包下载后,将在浏览器环境(或其他的小程序执行环境)中自动执行。其和应用程序的主
要区别是小程序执行环境有严格的安全规范,我们称之为“在沙箱内”(InSandbox),这是
由于Java运行时一直会有某个东西——即Java运行期安全系统——在监视着我们。虽然Java
1.1为小程序提供了数字签名,可选出能信赖的小程序去访问主机,但是我们并不需要这么
做,因为首先这比较麻烦,而且这些限制对我们来说并不起着决定性的制约因素,我们仍然
能充分利用计算机的计算资源!让我们看一下小程序运行环境主要有哪些限制:
二尘薹三!型!塑塑竺生簦堡型 一——
(1)小程序不能接触到本地的磁盘。这意味着不能在本地磁盘上写和读,我们不想一个小
程序通过WEB页面阅读和传送一些我们不想被传送的重要的信息,所以读取信息被禁
止了。写也是当然被禁止的,因为那将会引起病毒的侵入。当数字签名生效时,这些
限制会被解除。
(2)一个小程序只能访问下载此小程序的服务器,不能建立到其它服务器的连接,这也是
防范恶意的小程序自动连接到宿主不愿意连接到的地址的重要限制,是重要的保护措
施。当然当数字签名生效时,此限制会被解除。
以上两个是最主要的限制,对我们来说,这却并不算什么限制,所以以小程序的形式发
布计算包是最合适的选择。下面我们来看看计算结点是怎么工作的,小程序下载后。将自动
运行其中的Run方法,因为参数域是动态的,我们将在Run()方法中建立一个连向管理结点
的连接,来获得相应的参数域和子问题ID(注意在前面的讨论中我们把计算包和参数域的
下载等效地看作一个步骤,实际上是两步实现的),其中子问题ID是用来标识正在计算的
子问题的。在下载小程序的页面中,我们将以参数的形式设置给小程序它所获得的问题ID,
有了这个参数,就可以在EJB服务器中申请获得对应这个问题的一个参数域(参见问题分
解模块设计)并序列化返回,从而顺利的进行计算。我们在设计的时候扩展了小程序类Applet
成为一个自己定制的Computer类,它主要定制了一些和管理结点连接,获得参数域的方法,
因为这些都是静态的,我们定制好了一个基类,以后直接继承就可以了。需要指出的是,当
计算结点取回参数域并计算完成,提交结果成功后,小程序将重复地再次请求参数域进行下
次的计算,只要小程序在运行,它就周而复始地“请求计算一计算一计算完毕一提交结果一
请求计算?”,以期达到充分利用计算资源的目的,计算结点获得计算包和相应计算域的
具体流程示意图如下:
11.计算结果提交的设计
当问题计算完毕以后,计算结点将返回子问题的计算结果,其形式是一个实现了Result
接El的实例,同时子问题ID和问题ID也一起传回,好让管理结点知道这是哪个问题的哪
个子问题的结果。同Parameter接口类类似,因为结果的类型可以是千变万化的,我们不可
能以一概全,也不需要,所以我们只定义了Result接口类,增加了几个必须的方法和状态
■一个基于Java的网络计算模型
管理模块进行交互,各个问题的提交者还可以根据自己的需要定制自己的实现了Result接
口的扩展类,只要扩展类遵循可序列化的一些约定,就可以实现本身类的存储和读取。需要
注意的是,我们这里把总体的结果管理方法和子问题的结果管理方法放在同一个接口中,这
样做是为了简化模型的复杂度,减少总接121的个数,所以各个处于不同模块中实现Result
接口的实例实际实现的方法并不相同,要根据具体所起的作用而定,如计算结点端的Result
接口实例就根本无须不实现一些状态管理模块中需要的Result接口实例中的方法。下面先
介绍一下Result接口的具体定义:
publicinterfaceResult{
publicbooleanAddResult(ObjectChildResult);
publicbooleanIsEqualResult(ResultAnoth rResult);
publicObjectGetFullResult0;
publicObjectGetChildResult0;
其中AddResult方法将被状态管理模块使用向结果状态中添加结果,lsEqualResult方法
是状态管理模块中用来比较两个Result是否相等(它是我们冗余派发设计的需要),
GetChildResult方法是计算结点端实现的用来提交子问题的结果的方法,而GetFullResult方
法是问题设计者用来给出一个晟后计算结果的方法。我们把结果以Java中最基本的类
Object的形式传递,各个应用可以在Object类的基础上自由扩展相应的结果表达方式并保
持和管理结点端的兼容。在下一章的讨论中我们可以看到一个扩展的例子。需要指出的是,
结果被取回后,在EJB服务器中一段时间内仍然存储有它的拷贝,下次遇到同样的问题只
要结果仍然存在,直接调出结果就可以了。下面是Result接口在计算结点(小程序),管理
结点和EJB服务器中状态控制模块之间的交互流程示意图如下:
■一个基于Java的网络计算模型
3.3详细设计总结
本章详细讨论了此模型的内部设计,从具体的设计角度展示了此模型的实际构架及意
义。需要指出的是此模型还是有有待完善的地方,比如关于问题的分解部分,采取的方法并
不是完善的,正是它限制了可以解决问题的类型,如果更深入的分析下去,分解出更多的问
题类型模式,并在此基础上用几种模式共同工作,可以解决问题的范围将更加广泛了,当然
由于是松散的基于Intemet的网络计算,整体的问题解决类型还是局限于不需要密集交互的
计算任务。
一个基于Java的网络计算模型
第四章模型实现中的一些问题和一个应用
4.1模型实现中的一些问题
完成了对整个模型构造的分析,F面将要讨论一些实际实现时碰到的问题,有些问题在
设计的时候并不容易考虑到,但在实现的过程中将碰到,它们解决的好与坏直接影响着模型
的实际实用效果,下面将列举其中一些重要的问题并讨论他们的解决方法,需要说明的是这
只是针对问题出现后的一些措施,是在不影响模型原来的构造和设计的基础上进行的,如果
这些措施效果不好或者根本没法解决,那就说明模型设计本身就存在不合理的情况,必须修
改模型的设计了。
4.1.1Internet网络不稳定性的问题
由于此模型是基于Intemet环境下的,要面对的是各种接入设备,网络的不稳定性是首
当其冲要面临的问题,网络随时都有可能断路。幸好我们是基于HTlP协议的,它并不保持
连接,我们的计算模式也并不要求各种结点一直和管理结点保持连接。但是这并不意味着我
们可以不考虑网络断路的问题,因为每次连接的过程中都有可能发生断路,我们必须考虑到
各个连接过程中发生断路的情况。需要指出的是一些人为因素(如计算结点用户自己停止计
算)实际上是等同于断路的情况,就不再另行讨论了。我们假设管理结点和EJB服务器间
的连接是良好的(它们本身很可能就是同一台机器),下面通过的连接将会可能出现断路:
I.问题提交结点和管理结点之间的连接
如果在提交的过程中出现断路,问题结点会收到相应的断路信息,但它并不知道提交是
否完成。如果是在请求上传的时候发生断路,管理结点收不到完整的提交包,并不会对其处
理,只是抛出个意外提示一下管理员,提交结点下面都任何动作都将是从新开始,前面的中
断不会有任何影响。如果在管理结点返回给问题提交结点提交完成的信息时发生断路,这时
提交已经完成,管理结点已经处理了提交的完整程序包,发布到了EJB服务器中。尽管管
理结点知道断路了,但是现有的模型并没有做相应的处理,也就是说发布到EJB服务器中
后就不能再删除了。在对这种情况下,问题结点可能有继续采取下面两种动作之一:
(1)问题提交结点放弃了,这时管理结点并不知道,管理结点将继续按照第三章所说的步骤
进行处理直到问题的解决。接着管理结点通知问题提交结点问题已经解决,问题结点很“意
外”地收到了结果通知,会很高兴的去取回结果。
(2)问题提交结点并不放弃,再次提交,如果这次一切顺利,因为同样名字的问题已经有了,
并且管理结点发现在等待此结果者的列表中已经有了相同的邮件地址,根据3.2.1的讨论,
管理结点上实际上什么也不做,直接返回提交成功的信息。最后计算完毕问题提交结点将如
期收到计算完成的通知。如果这次再遇到断路,只不过重复我们刚才讨论的情况。
综合上述,问题提交结点提交计算任务时发生连接断路的情况并不对本模型造成多大的
影响,模型本身的容错性已经可以很好的解决此种情况。当问题计算结束时,因为整体计算
结果本身将存储在EJB服务器中一段时间(一般比较长,直到管理员彻底删除了这个问题),
二尘苎±!型!竺塑堡生竺竖型————
如果计算结点取回结果时发生连接断路,只要重新访问结果取回界面再取一次即可。
n.计算结点和管理结点之间的连接
计算结点只是在请求计算的时候连接到管理结点取得计算包和参数域,当问题解决结束
后再次连接到管理结点提交结果就可以了。我们只需要对这两种情况进行讨论:
(1)计算结点在请求计算时候的连接
首先,它将从管理结点取得计算任务的计算载体:扩展了的小程序。所以如果发生断路,
因为静态的小程序下载没有完成,小程序将不会运行,和管理结点的交互也不会发生,所以
这时是没有问题的。计算结点可以选择过一些时候再次尝试连接。如果小程序下载成功,正
如我们前面的章节3.2.3中所介绍,小程序将和管理结点建立连接以取得参数域,这个时候
仍然有可能发生断路!有下面两种情况:
A.如果这时小程序根本连不上管理结点,小程序会报告出连接错误给计算结点(为了保持
一定的健壮性,实现的时候可能已经尝试了很多次),其结果等效于小程序没有下载完成,
联系不会发生。
B.如果小程序连上了管理结点但在取回计算域的过程中发生断路,此时管理端已经做了
状态记录,而计算结点只能得到同样的断路通告,并不能区分这种情况和情况A,所以它只
是等同地认为断路了。不过这时候模型中的超时管理设计将发挥作用(参见状态管理模块的
设计)。虽然状态中做了记录和变化,但是这个子问题的计算必定要超时(因为永远不会完
成),此时的效果将等同于计算超时的处理,模型本身的容错性可以把此时的断路问题解决。
(2)计算结点在提交结果时候的连接
当计算结点完成计算后,小程序将再次跟管理结点建立连接来提交结果,这时如果发生
断路,可能这时小程序根本连不上管理结点,小程序会报告出连接错误给计算结点(为了保
持一定的健壮性,实现的时候可能已经尝试了很多次),其结果等效于小程序不能获得参数
域。如果小程序连上了管理结点但在发送计算结果的过程中发生断路,将有下面两种情况:
A.小程序还没有发送完计算结果就断路了,此时的情况和连接不上是等效的。管理结点不
会处理不完整的数据。
B.小程序已经发送完计算结果,但是在管理结点返回成功的信息时发生断路。此时管理端
已经做了相应的处理,而计算结点只能得到同样的断路通告,并不能区分这种情况和情况A,
所以它只是等同地认为断路了。我们不能简单地获得了计算结果就不管了,因为计算结点的
小程序很可能为了有一定的容错性当出现连接错误时进行多次尝试,这将可能导致同一个结
果的多次提交,这将使我们的冗余容错性失效。这种情况我们可以迂回解决,管理端接受结
果的时候只是把它放在一个缓冲变量中,如果返回给计算结点的时候没有意外,再把计算结
果真正写入状态管理模块,这样一来,就可以保证每次计算最多只有一次结果的提交了。
综合上述,计算结点提交结果时发生连接断路的情况也会不对本模型造成多大的影响。
二尘薹主!型!堕塑塑生苎燮型————
4.1.2系统的安全性问题
众所周知,系统的安全性对系统起着至关重要的作用,一个不安全的系统或模型将是非
常脆弱的,而且我们解决问题所依靠的计算结点是面向Intemet的,任何人都可以访问系统
的管理结点!而一些问题的提出者虽然希望大家帮助他进行计算,但是他其中的一些算法或
者信息并不希望成为重所皆知的秘密,所以本模型必须考虑一定的安全性或者方法来保障自
己和各个方面的利益。这样才能算一个比较完整的模型。因为本模型的原本目的并不是讨论
安全的问题,完美的安全体系将大大增加本模型的复杂程度和削弱它的意义,所以只是在模
型层次上做到尽量地安全。下面我们就几个方面讨论一下有关本模型的一些安全性问题。
I.网络传输的安全
网络传输安全本身就是一个很大的课题,也有很多这方面的研究,因为它是的比较底层
的,所以我们完全可以把我们的模型系统建立在它之上,具体实现时可以以HTTPS协议连
接来保持网络底层传输的安全性。我们来看看我们的模型中哪些交互信息需要一定的保护:
(1)计算任务提交结点和管理结点之间的交互:这将在下面的讨论中分别进行分析。
(2)计算结点和管理结点之间的交互:这个情况下我们必须加以保护,因为仿冒和窜改计算
结点小程序和管理结点进行的连接将扰乱管理结点的管理,导致问题无法解决。如果我们能
一眼认出这是我们自己发出计算包发出的连接请求的化,就可以把不符合规范的连接过滤掉
了,那么他们之间的交互就安全了。我们可以考虑在交互的信息中设置一个只有我们自己知
道的标志,表明这是个合法的请求,并用一个保密的算法处理一下(算法保密大大增强了它
的安全性)掩盖住这个标志,不管是窜改还是冒充,都无法知道怎么设置这个标志,而简单
的复制连接由于系统的容错性产生影响并不大,所以也就达到了目的。但这又牵涉到另一个
问题:小程序代码的安全性!如果有恶意的一方知道了产生标志的代码,照葫芦画瓢就可以
伪造了,关于这个我们将在IⅡ中进行讨论。
11.计算任务恶意提交
这是一个比较复杂的问题,系统很难判断一个问题是否是恶意或者是无用的。这个时候
需要一定的机制来制约。比如任务提交者必须先表明自己的身份(身份标识和防伪方面已经
有很多成熟的方法,这儿就不介绍了),这样一来就可以基本杜绝恶意任务的提交了。况且
由于小程序本身的限制,即使有恶意的小程序下载下来,对计算结点也不会造成什么破坏。
身份标识可以作为一个单独的系统,通过它后再进入本模型系统,所以也就没有把它也放入
本模型的设计中了。
111.计算代码的保护
从问题提交者的角度看,他希望大家帮他计算问题,但是他不一定希望自己的算法或者
一些敏感数据泄露出去,这时他必须考虑他自己代码的保护。由于个人的情况不一样,所以
模型本身并不对问题包作什么要求,只要合法的程序包即可。问题提交者可以根据自己的需
要选择一些Java程序的加密方法对自己的问题包进行处理。但是由于1.中所述的原因,模
型的实现中必须对计算结点和管理结点之间的连接部分代码保护起来。具体实现可以参考
Java编码模糊化和重排的有关原理,虽然不能从理论上完全防止代码破译,但是使编码的解
二尘苎王!竺!塑塑竺生竺蔓型——
读变得非常困难,基本可以实现预期的效果。而且这已经有现成的工具可以实用,在编译好
了以后直接处理一下就行了,这里就不再详细叙述了。
Iv.计算结果的保护
如果付费计算已经流行,你为了计算出结果付出了费用,这时你并不想把你的结果共享,
这时系统需要能够保护你的结果不被任意取回(虽然你可以做一些工作使结果必须再经过一
些处理才有效),这时需要有对计算结果保护的可能。而本模型把有着同样名字的问题看作
是一个问题,所以如果可以猜测你的问题的名字从而获得结果,这时如果你不想你以前问题
的计算结果被共享。实际上只要取一个不规范,很长的名字达到难以猜测的目的基本上就可
经过以上的讨论,基本上已经对本系统的安全问题有了个全面的说明,需要指出的是作
者并没有具体实现这些安全性,只是提出了解决问题的方法,以后可以把它逐渐加入到模型
的设计中去。
4.1.3容错性和扩展性问题
本模型设计的时候已经考虑了一些容错性,但是由于小程序本身的限制,不能访问宿主
的存储设备,所以其子问题的中间状态并不能保存,也就是如果小程序意外中止运行的化,
前面的计算就等于没有做了。小程序意外中止的情况有很多:比如运行环境被关掉了,宿主
机器出现当机等,由于这是无法避免和补救的,一般只要把问题分解的小一些就行了,但是
注意不能太小,否则管理结点的负担会加重,以至于来不及处理各种交互和请求了。
很明显,管理结点在整个模型中起着重要的作用,由于它要处理很多计算请求,结果提
交等,它必须具有很强的可扩展性。好在我们已经把它分解为表示层服务器(WWW服务
器)和应用服务器(Em服务器),相应的负载会平衡一些,况且服务器本身也具有很强的
扩展能力(可以做成机群来组成更强劲的服务器),这些基本上硬件和已有服务器软件带来
的扩展能力,本模型建立在它们之上,自然继承了这些特性。
4.2一个破解RSA算法的应用
4.2.1RSA算法简介
RSA算法是一种被广泛使用的公钥密码算法,著名的邮件加密软件PGP-.PrettyGood
Privacy就是基于RSA公匙加密体系的。RSA算法于1978年被提出。是第一个既能用于数
据加密也能用于数字签名的算法。它易于理解和操作,也很流行。算法的名字以发明者的名
字命名:RonRivest,AdiSham r和LeonardAdleman。但RSA的安全性一直未能得到理论上
的证明。它的安全性依赖于大数分解。公钥和私钥都是两个大素数(大于100个十进制位)
的函数。据猜测,从一个密钥和密文推断出明文的难度等同于分解两个大素数的积。它的密
钥对产生方法如下,
选择两个大素数,P和q。计算:
二尘苎王!竺!塑堕竺生塞塑型——
- 然后随机选择加密密钥e,要求e和(p.1)+(q-1)互质。最后,利用Euclid算法
计算解密密钥d,满足:
e+d=1(mud(P一1)+(q-1))
其中n和d也要互质。数e和u是公钥,d是私钥。两个素数P和q不再需要,应该丢
弃,不要让任何人知道。加密信息m(二进制表示)时,首先把m分成等长数据块ml,m2,.,
mi,块长S,其中2"s《=n,s尽可能的大。对应的密文是:
ci=mi^e(modn)(a)
解密时作如下计算:
mi=ci^d(modn)(b)
RSA可用于数字签名,方案是用(a)式签名,(b)式验证。具体操作时考虑到安全
性和m信息量较大等因素,一般是先作HASH运算。如果想要破解RSA密码就一定需要
作大数分解。假设存在一种无须分解大数的算法,那它肯定可以修改成为大数分解算法。目
前, RSA的一些变种算法己被证明等价于大数分解。不管怎样,分解n是最显然的攻击方
法。现在,人们已能分解140多个十进制位的大数。所以如果大数的分解能力越强,RSA
算法的脆弱性也越强,而一般单个计算机的能力是远远不够的。Rivest,Shamir和Adleman
用已知的最好算法估计了分解rl的时间与n的位数的关系,用运算速度为100万次/秒的计
算机分解500bit的n,计算机分解操作数是1.3×10”,分解时间是4.2x1025年。所以这里网
络计算的巨大优势就显示出来,如果一万台以上的计算机参与了计算,那分解的速度将大大
加快。下面,我们就来讨论一下怎么利用我们的模型进行分解计算。
4.2.2利用本模型进行大数分解
对于大数的质因数分解,试除法显然是最先想到的,虽然它速度比较慢,但实际上,目
前所有用于索性检验和因数分解的方法中又都少不了试除法。因为这里我们主要是展示本模
型的实用价值和可行性,具体的大数分解算法和优化这里就不再介绍了,我们只是采用稍微
增加一些优化的试除法来解决破解RSA加密算法中关键的部分:大数分解的问题。
I.计算主体的设计
首先我们实现一个小程序的扩展(模型中的Computer类),它是负责运算的主体,用试
除法来分解一个已知RSA算法中的n。计算中间加入了一些小的优化,对2,3,5的倍数不
再试除(对任意一个数是否是2,3或5的倍数很好判断),这样可以大大减少试除的次数又
不是很复杂。因为我们知道这个大数只有两个质因数,计算中只要找到其中的一个,另一个
质因数只要除一下大数就可以了,其具体流程图如下:
二尘茎±!型!盟塑竺生簦堕型——
II.参数域的设计
由于此问题原理比较简单,参数域并不需要很复杂的设计,只需传递一个上界,下界就
可以了,每个计算小程序只需从管理结点那儿获得自己试除的上界和下界就行了。需要注意
的是因为试除的都是大整数,不能用简单的整形变量表示,因为那很快就会溢出了,好在
Java语言有专门的大整数计算包,可以很好地解决大整数的加、减、乘、除的问题,可以在
此派上用场。
111.问题分解的设计
管理结点的问题分解模块是要问题提交者自己实现的,在这个实际的问题中,每次我们
将分解出~个上,下界让计算结点去试除,需要考虑的问题是这里并不能采取平均递增的方
法来分配计算域的大小,这也是分解问题时经常需要注意的地方,因为随着计算的深入(在
此问题中表现为候选试除数越来越大),计算量也将越来越大,同样是试除100个数,1000000
—1000100的计算域要比100--200复杂的多,耗时也将多很多,所以在分解问题的时候尽
量要保持计算量的尽量一致。但是没有计算之前很难估计实际计算量,可以在实现的时候先
在各个数量级分别测试一下需要的时间,大概估计一下计算量,然后再对不同数量级进行计
算任务的分配,稍微平衡一下就可以了,并不需要过分强求。
Iv.子问题结果的提交设计
当子问题解决后,计算结点向管理结点提交结果并取回下次用于计算的计算域,这里的
结果表示并没有什么特别,只是向管理结点表明找到了还是没有找到,如果找到了,返回那
个找到的质因数就可以了。
个基于Java的网络计算模型
由于此问题有很好的可并行性,在此模型可以大大地增加对RSA算法攻击的力度。这
也是本模型当初面向的主要应用之一。这个例子算法比较简单,运用起来也比较方便,不需
多少复杂的设计,而其他很多类似的问题并不是那么容易解决的了,比如要彻底对任意一个
大数分解质因数(可能有很多质因数),就必须对子问题的结果进行进一步处理才能最终得
到结果。这些都需要问题提交者自己分析和设计,问题的种类千变万化,本模型实质上是提
供一个标准化,自动管理控制的工具而已。
二尘墨三!!:!盟堕塑生兰堡型——
第五章总结和展望
5.1基于Java的网络计算模型总结
5.1.1本模型提出的回顾
本文的初始想法是起源于充分利用空闲计算机的计算能力,最典型的例子就是实验室的
机器晚上有很多都是一直运转着的(特别是服务器),所以如果能利用这些空闲计算机的计
算能力将可以做很多事情。随着参考了一些前人的研究成果,发现大家的研究方向都是基于
高速网络的机群运算和复杂的网格计算,这些课题都很庞大和复杂,结点之间必须非常频繁
的交互,而且一个完整的系统需要考虑到方方面面,在一些简单问题上并不是很实用。况且
很多研究成果也是不公开的,因为这牵涉到高性能网络计算机的研究,对国防,军事领域有
着重要的作用。为了能充分简化网络计算模式,实实在在地利用上空闲计算机的计算能力,
作者认为以Java技术为基础,把计算环境拓展到任何能连接上Intemet的计算设备将是一个
很好的尝试。因为作者对Java技术比较熟悉,深知它的优越性对此种类型的网络计算来说
是恰到好处的(可以参考第二章中有关的叙述),接着作者又参考了一些资料,发现已经有
人在这方面做过一些研究,并且基于Java的网络计算被公认为是一种比较又前途的方法(这
一方面也证明了作者想法的正确性),但是那是几年前的事情了,现在Java技术的巨大发展
给这种方法赋予了新的生命。所以作者就在此基础上提出了一个新的基于Java的网络计算
模型。这个模型并不是很复杂,因为本来作者的目的就是简化的网络计算,但是这个模型很
实用,虽然它不能解决所有的问题,但是对一两类问题比较有效,况且可以继续发展此模型
中的问题分解模块来适应新的问题类型。一开始对一些关键性技术做了些研究,得出结论是
此模型技术上是完全行的通的,接下来就是具体的设计这个模型了,前后有一些反复。比较,
毕竟一个人的能力是有限的,不能一下子做到很完善,但是它确实有着实用价值,性价比很
高,不需要什么特殊的设备和技术就能实现。为了说明问题,在第四章中作者设计了一个实
用的例子,它是比较典型的一类问题,完成它以后作者感到自己的工作终于有了些实际用处。
这就是整个模型提出的过程,在此作一个小结,作者希望这个模型的规范能被更多的人所使
用,完善并标准化,那将是作者最乐意看到的事情。
5.1.2本模型有待发展的方面
1.问题分解的模式
此模型有待继续探索的首要问题就是分解问题的方法,现在采用的静态计算包加动态参
数域的方法有一定的局限性,不是所有的问题都能这样分解,可以考虑更好的问题分解策略。
比较容易实现和想到的是多分解模型协同工作,它也是比较实际的方法。对各个类型的问题
提出不同的分解模型,用不同的分解模型来解决不同类型的问题,设计上只要改动问题分解
模块的设计和一些小细节就能完成,因为时间上的问题作者没有来得及把它放入现有的模型
的设计中。
二尘茎主!型!盟塑竺生竺堡型——
II.关于一些优先级和参数的问题
考虑到以后可能有提供计算能力来收取一定费用的可能,必须在系统中加入一定的优先
级策略,付费的用户可以得到最先的计算,在请求队列管理模块中做一些修改即可以了。同
时,计算结点有时并不是想把自己的全部力量用于计算(特别是服务器)或者本身由于结点
的计算能力有限,并不能提供强劲的计算能力,这时分配的任务必须小一些,这些需要计算
结点在请求计算的时候就表明自己的意愿或可提供的计算能力,任务分解模块中就要随之相
应的做出反映,做到力所能及的分配。这又牵涉到衡量任务量的问题,比较简单的解决方法
是尽量小的分割任务,碰到大计算能力的结点就把几块小任务合起来分配给它,碰到小计算
能力的结点只分配一块就行了。
5.2基于Java的网络计算的发展展望
5.2.1现阶段基于Java的网络计算的一些有利因素
现阶段Java运行环境进入无线移动设备的一些硬件和软件已经有了实践性的产品!
Sun、NextelCommunication及手机厂商Motorola公司,共同合作,率先推出Java技术在移
动通讯上的应用,并在美国地区率先提供这项新服务。包括Motorolai85s以及i50sx两款手
机,目前都已经整合Java技术,可提供使用者动态、个人化的互动服务,这两款手机都已
经在今年3月份开始供应。最新的服务内容包含了许多垂直应用,例如特殊的商用计算器、
费用报表产生器以及游戏开放下载。Sun表示,对消费者而言,现阶段手机上的文字式静态
内容,未来将被J2ME技术提供的交互式服务取代。
可以看到Java的运行环境已经越来越广泛,即将成为现实的电话计算环境,越来越红
火的PDAJava小程序执行环境也都是非常好的例证,说不定明天您家的冰箱也可以执行
Java小程序!这一切预示着我们的计算结点将会越来越广泛,而这将是推动基于Java的网
络计算迅猛发展的直接动力。当然个人计算机计算能力的蓬勃发展和网络在速度和稳定性方
面的进步也是重要的因素,毕竟它们是现阶段最主要的运算载体。
s.2.2基于Java的网络计算的前景
由于前面提及的一系列有利因素,基于Java的全球计算似乎并不是很遥远,每一部手
机,每一件电器,每个设备似乎都能计算,这也是未来网络计算的发展目标。然而这中间还
有许多管理和制度的因素在起作用,不以规矩不成方圆,良好的体制和标准将起着重要的作
用。作者认为未来的发展方向将是付费计算,你参加了我们的计算,我们将给你一定的回报,
你需要大家一起计算,你必须付出一定的费用。这需要一定的信用和付费制度,虽然很复杂。
而这又是必须的,因为只有那样的商业化才能推动它的标准化,从而发展的更迅猛,更完善。
它的前景才会更加光明。
5.3结束语
团结就是力量,这是网络计算的口号,齐努力,共计算,可以完成更复杂的计算任务
最后,衷心地希望本文提出的模型能给基于Java的网络计算起一些推动作用。
二全茎主!型!堕塑塑盐竺堡型 .——
【ll胡凯,宋京民。阚志刚,武庄,“网络计算新技术”,科学出版社,2000。
[21 胡凯,胡建平,王强,“分布式并行计算网络体系结构研究”,小型微型计算机系统,V01.21No.2000·
13】 胡凯,王强,胡建平,“机群并行计算中负载共享的关键问题,”计算机科学,20007。
【4】JurgenFriedriehs,HenriJubi ,JalapenoTeam,“JavaThin-ClientProgrammingfortheNetworkComputing
Environment'’,PrenticeHall,Paperback,Bk&CdRomedition,PublishedSeptember1998
【5】RajkumarBuyya,DavidAbramson,andJonathanGiddy,Nimrod/G,“AnArchitectureforaResource
ManagementandSehedulingSysteminnGlobalComputationalGrid”.
【6】6 HenriGasanova,JackDongarra,NetSolve,“ANetwork-enabledServerforSolvingComputationalScience
Problems”
【717 JackDongarraete,“AdaptiveSchedulingforTaskFamingwithGridMiddleware”
【8】ProceedingsoftheWorldComputerCongress2000(WCC2000),Beijing,China,“TaskSchedulingIn
NetworkParallelComputingEnvironment'’,August21·25,2000.
【9】EdRoman,”MasteringEnterpriseJavabeans”,JohnWiley,Paperback,Bk&CdRomedition,Published
September1999.
【10】Narayanan,JuhneLiu,SNamNamyanan,McGrawHill,“EnterpriseJavaDevelopersGuide:Java,
Javabeans,ServletsandJini(EnterpriseComputingSeries)”,Paperback,Book&Cdroediti n,Published
【11】RichardMonson-Haefel,“EnterpriseJavaBean ,2ndEdition”,O’Reilly&Associates,Paperback,2nd
edition,PublishedApril2000.
f12】WroxMultiTeam,“ProfessionalJavaServerProgramming,J2EEEdition”,WroxPress,Hardcever,2nd
edition,PublishedSeptember2000.
【13】Burnett,Payne,“RSASecurity'sOfficialGuidetoCrypotography'’,McGrawHill,PublishedApril2001.
【14】Schneier,“SecretsandLies:DigitalSecurityinaNetworkedWorld”,JohnWiley,PublishedAugust2000.
【15】Hartman,”EnterpriseSecuritywithEJBandCORBA(OMG)'’,JohnWiley,PublishedMay2001
【16】Brenton,”MasteringNetworkSecurity”,Sybex,Paperback,Cd-Romedition,Publish dOctoberl998.
【l7】HXMel,DorisM.Baker,“CryptographyDecrypted”,Addison-Wesley,PublishedDecember2000.
【18lSimsonGarfinkel,”POP:PrettyGoodPrivacy”,O'Reilly&Associates,Paperback,PublishedJanuaryl995
【19]WilliamStallings,”NetworkSecurityEssentials:ApplicationsandStandards'’,PrenticeHall,Paperback,
PublisIlcdNovember1999.
【20】ElliotteRustyHarold,‘'JavaNetworkProgramming”,O'Reilly&Associates,Paperback,2edition.Published
August2000.
【21】MarcoPistoia,“Java2NetworkSccurity'’,PrenticeHall,Paperback,2ndBk&Dkedition.PublishedAugust
【22】RichardSteflik,PrashantSridharan,“AdvancedJa Networking”,PrenticeHall,Paperback,2edition,
PublishedApril2000
经过一年多的学习与实践,本人的论文工作终于告一段落,这篇论文得以完成首先归功
于我的导师张世永教授。在研究生的学习生活中,他悉心指导和谆谆教诲,并为我提供了良
好的学习和研究环境,使我能够在专业技术和工作能力上得到了长足的提高和进步。从该项
目的确立开始,张老师又一直给以鼓励和支持,多次讨论论文进展情况,并不断的给出指导
和帮助,在此谨表示衷心的感谢。
同时,我还要感谢钟亦平老师、李松年老师、傅维明老师、李莹老师、吴勇老师研究生
三年以来对我项目开发、理论学习上的悉心帮助。
感谢黄茹、阮文俊、桂芳等同学在整个论文的写作过程中为我提供的帮助和支持。
最后,我还要感谢我的父母和亲人。一直以来,他们都给我以莫大的鼓励和支持。
正是在这许多人的帮助下,我的论文才得以完成。

我要回帖

更多关于 sketchfab 模型提取 的文章

 

随机推荐