毕业设计外文翻译-中文版

本科生毕业设计（论文）外文科技文献译文译文题目(外文题目)学院(系)Socket网络编程的设计与实现A Design andImplementation of Active Network Socket Programming机械与能源工程学院专学业号机械设计制造及其自动化071895学生姓名李杰林日期2012年5月27日指导教师签名日期摘要：编程节点和活跃网络的概念将可编程性引入到通信网络中，并且代码和数据可以在发送过程中进行修改。

最近，多个研究小组已经设计和实现了自己的设计平台。

每个设计都有其自己的优点和缺点，但是在不同平台之间都存在着互操作性问题。

因此，我们引入一个类似网络socket编程的概念。

我们建立一组针对应用程序进行编程的简单接口，这组被称为活跃网络Socket编程（ANSP）的接口，将在所有执行环境下工作。

因此，ANSP 提供一个类似于“一次性编写，无限制运行”的开放编程模型，它可以工作在所有的可执行环境下。

它解决了活跃网络中的异构性，当应用程序需要访问异构网络内的所有地区，在临界点部署特殊服务或监视整个网络的性能时显得相当重要。

我们的方案是在现有的环境中，所有应用程序可以很容易地安装上一个薄薄的透明层而不是引入一个新的平台。

关键词：活跃网络；应用程序编程接口；活跃网络socket编程1 导言1990年，为了在互联网上引入新的网络协议，克拉克和藤农豪斯[1]提出了一种新的设计框架。

自公布这一标志性文件，活跃网络设计框架[2，3，10]已经慢慢在20世纪90 年代末成形。

活跃网络允许程序代码和数据可以同时在互联网上提供积极的网络范式，此外，他们可以在传送到目的地的过程中得到执行和修改。

ABone作为一个全球性的骨干网络，开始进行活跃网络实验。

除执行平台的不成熟，商业上活跃网络在互联网上的部署也成为主要障碍。

例如，一个供应商可能不乐意让网络路由器运行一些可能影响其预期路由性能的未知程序，。

因此，作为替代提出了允许活跃网络在互联网上运作的概念，如欧洲研究课题组提出的应用层活跃网络（ALAN）项目[4]。

在ALAN项目中，活跃服务器系统位于网络的不同地址，并且这些应用程序都可以运行在活跃系统的网络应用层上。

另一个潜在的方法是网络服务提供商提供更优质的活跃网络服务类。

这个服务类应该提供最优质的服务质量（QOS），并允许路由器对计算机的访问。

通过这种方法，网络服务提供商可以创建一个新的收入来源。

对活跃网络的研究已取得稳步进展。

由于活跃网络在互联网上推出了可编程性，相应地应建立供应用程序工作的可执行平台。

这些操作系统平台执行环境（EES），其中一些已被创建，例如，活跃信号协议（ASP）[12]和活跃网络传输系统（ANTS）[11]。

因此，不同的应用程序可以实现对活跃网络概念的测试。

在这些EES 环境下，已经开展了一系列验证活跃网络概念的实验，例如，移动网络[5]，网页代理[6]，多播路由器[7]。

活跃网络引进了很多在网络上兼有灵活性和可扩展性的方案。

几个研究小组已经提出了各种可通过路由器进行网络计算的可执行环境。

他们的成果和现有基础设施的潜在好处正在被评估[8，9]。

不幸的是，他们很少关心互操作性问题，活跃网络由多个执行环境组成，例如，在ABone 中存在三个EES，专为一个EES编写的应用程序不能在其他平台上运行。

这就出现了一种资源划分为不同运行环境的问题。

此外，总是有一些关键的网络应用需要跨环境运行，如信息收集和关键点部署监测网络的服务。

在本文中，被称为活跃网络Socket编程（ANSP）的框架模型，可以在所有EES下运行。

它提供了以下主要目标：♦♦通过单一编程接口编写应用程序。

由于ANSP提供的编程接口，使得EES的设计与ANSP 独立。

这使得未来执行环境的发展和提高更加透明。

♦♦ANSP 针对不同执行环境之间的互操作性问题。

通过的ANSP设计，不同EES的优点和缺点显而易见。

这将有助于在将来设计更好的EES。

ANSP 的主要目标是使在ANSP 下编写的所有应用程序，可以运行在ABone测试平台。

而ANSP框架在统一网络环境下是必不可少的，我们相信，在不同环境下的通用性，对未来执行环境的发展是有利的。

ANSP并不是取代所有现有的环境，而是研究启用新的网络服务执行环境。

因此，ANSP 设计是对所有执行环境安装薄而透明的应用层。

目前，它的代码自动加载依赖于底层环境。

因此，部署在路由器的ANSP是可选的，不需要任何执行环境的变化。

2 针对ANSP的设计问题ANSP 统一现有各EES的编程接口。

ANSP 设计在概念上类似于中间件的设计，为不同的EES提供适当的翻译机制。

一个统一的接口只是整个ANSP平台的一部分。

有很多需要考虑的问题，除了翻译一套编程接口，在不同EES下可执行文件调用，也包括其他的设计问题，例如，♦♦♦♦♦统一的线程库处理线程操作。

全球性软件存储，可以在给定的路由器上进行不同环境下的信息共享。

统一的解决方案用于不同的环境，更重要的是，路由信息交换机制应横跨EES获得全球统一的网络视图。

应该是独立于任何活跃网络编程语言的编程模型。

最后，翻译机制要隐藏头结构的异构性。

A. 异构性编程模型在程序调用时，每个执行环境提供各种抽象的服务和资源。

一套组件模型每个部分都有其自己的编程接口。

抽象的封装编程模型[10]是在活跃网络中最流行的设计，这种模型在ANTS[11] 和ASP[12]使用，并正被ABone支持。

虽然他们是在相同的封装模型基础上开发的，但各自的组件和接口是不同的。

因此，在一个EES 上的程序不能运行在其他EES 上。

ANTS和ASP的编程模型如图1 所示。

ANTS包括三个不同的组件：应用程序，封装，和执行环境。

存在针对唯一来源和目的地路由器的应用程序用户接口。

然后，用户可以指定其定制的网络行为。

根据程序的功能，应用程序发送一个或多个封装进行操作。

这两个应用程序和封装工作的执行环境，为其内部的编程资源提供输出接口。

每次访问路由器时封装便执行其操作。

当它到达目的地，在目的地的应用程序就会以封装进行回复或提示用户事件已经收到。

ANTS 的一个缺点是，它仅允许“引导”应用程序访问。

图1 ANTS和ASP的编程模型相比之下，ASP不限制用户运行“引导”应用程序。

其程序接口与ANTS不同，但ASP 也由三个组成部分：客户端应用程序，环境和AA组件。

应用程序客户端可以在活跃或不活跃的主机上运行。

它可以通过简单的请求消息发送到EES来激活应用程序。

客户允许其用户在附近的活跃路由器触发操作。

AA组件是网络服务的核心，其规格分为两部分。

其中一部分指定其来源和目的地路由器的行动，其作用类似于ANTS中的应用，但它不提供与用户交互的直接接口。

另一部分定义了它在内部网络中的行为，与ANTS 中封装的功能行为相似。

为了解决这两种模式的异构性，ANSP需要引进一套新的编程接口，它的接口和执行模型映射到内部路由器的EES。

B. 统一线程库为了各个实例之间不互相影响和访问其他信息，可执行环境必须保证各个实例间的独立性。

有多种方法来执行访问控制。

一个简单的方法是为实例应用程序配备一个虚拟机。

这依赖于虚拟机隔离服务的安全设计。

ANTS 就是采用这种方法的一个例子。

然而，使用多个虚拟机需要的资源量相对较大，并可能在某些情况下，效率低下。

因此，某些环境，如ASP，允许网络服务在虚拟机上运行，但只允许其有限地访问自己的包库。

例如，ASP提供强制访问控制的线程库。

针对这些线程访问机制的差异，ANSP提供允许不同线程机制统一访问的新线程库。

C. 软存储软存储允许封装在路由器上插入和检索信息，从而使多个封装能够交换网络内的信息。

然而，网络服务在不同的路由器环境下执行时容易发生问题，尤其是当网络服务在一个环境中插入信息，稍后在相同路由器但是不同环境下检索数据时这个问题尤其严重。

由于执行环境不允许交换信息，网络服务无法检索其以前的数据。

因此，我们的ANSP 框架需要考虑到这个问题，并提供在每个路由器上进行数据访问的软存储机制。

D．统一网络的完整视图当用ANSP编写应用程序时，它便可以在不同环境下完美运行。

以前基于不同EES的小型分区网络可以合并成为一个大的网络，整个大网络的拓扑结构也就显得很有必要。

然而，不同的执行环境有不同的解决方案和专有的路由协议。

为了合并这些分区，ANSP 必须提供一个新的统一的解决方案。

这项新计划在任何环境下都能由ANSP编译出来。

定义了新的方案之后，新的路由协议可以实现在不同的环境之间交换拓扑信息。

这使得在各个网络环境中，其网络拓扑结构都有完整的视图。

E．独立语言模型任何编程语言都可以在可执行环境下编写，Java以动态代码承载能力使其成为最常用的语言之一。

实际上，ANTS 和ASP 都是用Java开发的。

然而，如图2 所示的活跃网络架构不限制使用其他语言开发执行环境。

例如，Abone中的anted 作为活跃网络后台进程提供路由器上多个执行环境的工作空间。

又如，PLAN 将在Abone上部署在OCaml中。

虽然现在的网络设计可以用任何语言在多个环境中进行编程，但是缺少使得应用程序在这些环境中完美运行的工具。

因此，ANSP 需要解决的问题之一就是设计一种可以使用不同编程语言的编程模型。

我们现在着重考虑ANTS和ASP 的设计，但PLAN 将是下一个待解决问题并提高ANSP的设计。

图2 ANSP框架模型F.封装头结构的异构性在不同的EES下头结构是不同的。

他们执行相关的信息，例如封装，封装的种类，来源和目的地。

当在目标环境中执行某些决定时这个信息是非常重要的。

一个统一的模式，应允许其程序代码在不同环境下执行。

然而，封装头阻止不同的环境来解析它的信息。

因此，ANSP应在目标环境收到这些信息之前进行相应头信息的转译。

3ANSP 编程模型下面我们将讨论提到过的ANSP设计中编程模型的问题。

这个建议框架提供了一套允许在所有执行环境下运行应用程序的统一的编程接口。

该框架如图3所示。

它是由两层活跃网络架构集成的，并且这两层都可以独立运作。

上层的应用程序提供一个统一的编程模型，下层的应用程序为在不同环境下的应用提供适当的转译过程。

这项服务很必要，因为每个环境都有其自己的头定义。

ANSP 提供了一套服务和资源的抽象编程调用。

以封装为基础的模型已用于ANSP并映射到ANTS和ASP 的模型中。

因此，ANSP 允许应用程序通过一系列单一接口访问不同环境下的编程资源。

映射必须以一致和透明的方式进行。

因此，ANSP好像是提供执行环境的应用程序，而实际上，它是一个能够使用底层所提供服务的重叠式结构。

ANSP 编程模型是基于四个组成部分之间的相互作用：客户端应用程序，应用程序存根，封装，服务器。