现今较为流行的 *** 作系统Linux,本着开放、自由的精神吸引了全世界的目光,但将它应用于嵌入式实时环境还有许多缺点。特别是在运行内核线程时,Linux 关闭中断,而且分时调度虚拟文件系统的时间不确定性、缺乏高精度的计时器等问题都是需要解决的,所以在Linux 上进行实时改进,建立具有实时应用能力的 *** 作系统是现代嵌入式 *** 作系统的解决方案,也日益成为人们关注的课题。
目前,大多数嵌入式设备都具有存储容量小、处理速度慢和网络应用单一等特点,在这样的嵌入式系统中应用传统的单块式网络协议栈就存在问题:一是如果协议栈中某个子协议功能需要升级,就要升级整个协议栈甚至重新编译全部内核文件,工作流程复杂;二是协议栈不够灵活,不能根据嵌入式系统对网络通信的实际需求配置其内容。
2 构件技术介绍早在60 年代,“软件构件”与“软件组装生产线”思想在国际北大西洋公约组织软件工程会议上被提出来,从此,采用构件技术实现软件复用,采用“搭积木”的方式生产软件,成为软件业长期的梦想。然而,由于技术水平的限制,在很长一段时间内,构件技术只是作为一种思想存在,直到CORBA 、J2EE、.NET 出现,中间件兴起以后,构件技术才逐渐走向现实。
构件最大的特点是可以不断复用、降低成本、缩短开发周期。从构件技术的实现来看,它规定了一种普遍使用的抽象“标准”,即规定了一组相同的结构类接口来实现动态交流。通信协议引入构件技术设计,可提供代码的可重用性,使程序开发周期缩短,分工更加明细,使整个协议体系具备了更好的可配置性、高效性、可重用性、可扩展性和可表达性。从而解决了网络通信中存在的四个基本问题:基本的构件互 *** 作性、协议版本升级、实现语言无关性、透明的跨进程互 *** 作性。
软件构件技术是建立在面向对象技术之上的,它提供了比面向对象技术更为高级的抽象,通常是对一组类进行封装,通过固定的接口来调用该构件所提供的方法。构件技术成为了嵌入式 *** 作系统和嵌入式应用软件的发展趋势。利用构件技术把单块式的网络协议分割成多个独立的构件,每一个构件都可以被新的构件更新、替换,一组相关的构件提供特定的服务。因此,系统就可以通过选择相应的网络协议构件进行组装来通信。
3通信协议构件化随着嵌入式系统与网络的日益结合,在嵌入式实时 *** 作系统中引入TCP/IP 协议栈,以支持嵌入式设备接入网络,成为嵌入式领域重要的研究方向。但是传统的TCP/IP 协议实现存在实时性能较差,不能满足实时性要求高的嵌入式领域;传统TCP/IP 的实现过于复杂,需占用大量系统资源,而嵌入式应用的系统资源往往都很有限;传统的TCP/IP 协议系统是基于单块式体系结构的,即嵌入式实时 *** 作系统中引入的协议是以单块方式设计并加以实现的,随着网络技术的不断发展,以及一些新应用不断增长和变化的要求,这种通用的单块式结构的协议往往不能满足需求。因此,需要把传统TCP/IP 在不违背协议标准的前提下加以改进实现,使其实时性得到提高,占用的存储空间尽可能少,从而满足嵌入式应用的要求。
Linux 可针对用户的需求,动态载入和卸载 *** 作系统构件,这种模块化机制为通信协议构件化提供了前提条件。用户可以根据需要,在不对内核重新编泽的情况下,能将模块动态地载入内核或从内核移出,内核可以仅实现一些基本功能,系统的可扩展性功能就留给模块来完成,从而使内核的大小和通讯量都达到最小。因此,在Linux 中实现协议构件化可以依赖模块化机制,协议构件由Linux 模块来实现,模块能动态地载入内核或从内核移出,而不需要对内核重新编译。
本文针对嵌入式服务器的网络实时通信的应用,以经过实时改进和裁剪的Linux *** 作系统作为协议构件化的平台,对的TCP/IP 协议栈进行构件化。
1 通信协议构件化原理
2 通信协议分解
为了使协议构件具备动态链接、信息封装、统一接口等特性,首先要合理分解通信协议,这关系到通信协议构件的粒度。从粒度上来看,构件的粒度越小,协议划分越细,协议构件越多;构件粒度越大,协议划分越粗,协议构件越少。
协议构件粒度的大小,决定了协议构件模块化、信息封装性、局部化的程度,为此必须保证协议构件的独立性。一旦构件具备良好的独立性,建立在协议构件之上的应用程序构件就更容易开发,接口也会简化;独立的模块也比较容易测试与维护,修改工作量小,错误传播范围小。如果粒度过小,虽然协议构件独立性增强,但是构件的接口就增加了,给构件的组合、构件的管理带来了很多的困难。如果粒度过大,构件的尺度增加,独立性降低,各个构件之间的关联度也会增加,不利于构件的动态替换与更新。
粒度的大小可以用两个定性标准来衡量,分别是内聚和耦合。耦合衡量不同构件彼此之间相互依赖的紧密程度;内聚衡量一个协议构件内部各个元素彼此结合的紧密程度。在对协议进行构件化的时候,采取的策略应当尽量使协议构件之间的耦合度降低,独立性增强,加强内聚性。
目前对构件的粒度还没有统一的要求,由于构件是一个高内聚的软件包,只要符合高内聚的原则,则构件的粒度大小可不限。
3.1.2 通信协议构件化方法
由上节可知,通信协议分解没有统一的要求,所以,可以从多个角度对通信协议进行构件化。例如,按构件的功能可进行基本协议构件、通用协议构件、对各领域的专用协议构件或子系统协议构件化;按构件的使用方式可进行静态的和动态的构件化;按构件的结构可进行原子构件及由多个构件*的组合构件化;按协议栈的分层结构可进行层次构件化。本文以Linux 下的TCP/IP 协议层次结构(如图1 所示)为基础,按层次构件化。即将ARP、IP、ICMP、UDP、TCP 协议从Linux 内核中分离出来,按每个协议完成的功能划分成不同的模块,每个模块作为一个构件。每个构件用一个指针函数实现,这样,一个基于嵌入式Linux 的应用系统在内核启动时可按需求动态组装协议功能,形成不同配置通信协议栈,显示了系统网络通信的灵活性。
考虑到TCP 协议是面向连接的、端对端的可靠通信协议,为保证远程客户端与本地嵌入式系统服务器的正确通信,采取了相应机制来保证它的可靠性和实时性,即连接的建立与关闭、超时重传机制、数据包确认机制、流量控制等。因此,将TCP 协议按应用功能划分成客户端模块和服务器端模块,前者主动建立连接,后者*连接,连接建立后双方进行数据信息的发送或接收。
相对于TCP 协议,ARP、IP、ICMP、UDP 等协议功能较简单,对它们不划分模块,每个协议按其完成的功能设计成一个构件,但考虑到嵌入式系统的实时性,去掉了不必要的功能。UDP 协议设计时不考虑数据校验方法,只考虑数据的发送和接收功能。ICMP 协议设计时仅考虑了目的端不可达、源端抑制、超时、改变路由等差错和回送请求处理。IP 协议设计时主要进行路由、向相邻协议层传递数据包,而不考虑分片、重装功能。ARP 协议主要负责将局域网中的32 位IP 地址转换为对应的网卡的MAC 地址,它的功能包括发送ARP 请求和响应对方的ARP 请求,动态维护一个ARP 高速缓存。
3.1.3 通信协议构件组装
通信协议构件组装过程如图2 所示。通信协议构件放在构件库中,系统运行时,嵌入式Linux *** 作系统调度协议组装模块,由该模块依据系统网络功能需求从构件库中取出相应构件,动态配置通信协议栈。
因此,组装的主要功能是负责实现嵌入式Linux *** 作系统和构件库的交互、监控构件的运行状况,并记录构件的特征以反馈给构件库。
3.2 通信协议构件化的实现
本文借鉴文献的思想,并结合上面提出的方法来实现通信协议构件化。各协议的实现类似,下面以TCP 协议为例说明实现过程。
将协议栈初始化文件中为协议分配内核存储空间、向内核保存TCP 协议栈的链表结构、注册、协议本身初始化的内容移入其模块中,在模块开始部分完成分配存储空间、注册、初始化等,在模块结束部分完成释放模块所占内核空间、取消注册、进行重置等。
修改协议实现文件tcp.c 和tcp.h ,创建新的模块文件,协议实现文件中仅保留被其它协议使用的变量,其它内容放在新建的模块文件中。
协议提供给其它协议的函数接口,由函数名调用改为函数指针调用,修改头文件,为该新的接口实现添加定义及声明,并将函数指针初始化指向一个空函数体。将其它协议中原来通过函数名调用改为相应的函数指针调用,这些函数指针是该协议构件的接口,可以保持不变,而接口提供的功能可以依据需要随时修改。
修改网络部分的内核符号表文件,既包括修改之后为其它协议提供的接口,又包括模块化之后需要的其它协议提供的接口。
修改Makeflie 文件,增加相应的模块化文件列表。
4 通信协议测试构件化的协议的运行情况在MagicARM2200 目标板上进行测试,测试前需要配置软硬件环境,配置过程如下:用串口线和简易仿真器连接PC 机和目标板,使用两条独立的网线分别将它们连接到以太网;在PC 机上安装虚拟机5.5 和Red Hat Linux 9 ,将经过实时改进和裁剪的Linux 移植到该目标板。
4.1 测试ARP 协议构件
在内核无ARP 协议支持时,为了显示ARP 缓存中的MAC、IP 地址信息,运行arp -a 命令,结果为空,并且其它网络应用都不能工作,整个系统的网络部分由于该底层协议的失效而瘫痪。将ARP 协议构件用insmod 命令装入后,网络部分恢复正常。
4.2 测试ICMP 协议构件
在内核不加载ICMP 协议构件时,从外界ping 主机,ping 命令显示超时,即ping 不通。内核接收及处理传来的ICMP 数据包的函数接口找不到相应的功能实现,不能正常返回确认消息包。在将ICMP 协议构件用insmod 命令装入后,处理数据包的函数正确执行,显示能够ping 通。响应时间如表1 所示。
从表1 可以看出,当ICMP 协议作为模块被加载后,ping 命令的响应时间比该协议编译进内核的长,增长的幅度为(0.668-0.611)/0.611=0.093 ,性能下降不超过1%。而且,从内核启动速度来看,构件化ICMP 协议的结果,由于构件化的内核在网络部分启动过程中没有初始化ICMP 协议部分,启动速度略有提高。
4.3 测试UDP 协议构件
为了便于观察系统性能的变化,本文采用Linux 网络性能测试软件Netperf 对UDP 协议构件进行测试,主要测试UDP 的批量数据传输性能、请求和响应性能。测试结果如表2 所示。
从表2 可以看出,协议构件化之后的网络性能有损失,其数据传输性能的下降幅度为(l55.2-140.3)/155.2=0.096 ,请求/响应性能的下降幅度为(620.1-*.9)/620.1=0.025 ,它们都低于一个数量级。
4.4 测试TCP 协议构件
在目标板和PC 机之间进行测试,PC 机作为客户端,目标板作为服务器,并编写客户端和服务器测试程序。在内核不加载TCP 协议构件时,运行客户端程序,PC 机提示不能和服务器连接;加载TCP 协议构件后,再次运行客户端程序,观察PC 机,显示连接成功,在目标板上键入字符,在PC 机上可以显示接收到的字符。
从上面的测试结果可知,对Linux 下的TCP/IP 构件化后,尽管系统性能会略有损失,但损失不大,用此较小的代价可以换取升级、维护的成本大大降低、新协议开发时间大大缩短,从而说明构件化协议的可行性和优越性,在实际应用中可以认为是一种有效的方法。
5 结论本文针对嵌入式服务器的网络实时通信的应用,将构件技术引入Linux 的TCP/IP 协议设计中,提出了一种构件化TCP/IP 协议栈中主要协议的方法,并对构件化的协议进行测试,结果表明构件化的协议可以动态载入实时改进和裁剪的Linux 系统,不仅减少了嵌入式Linux 内核的尺寸,而且增强了系统网络通信协议设计的灵活性。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)