进程间通信范文

时间:2023-03-04 16:29:26

进程间通信

进程间通信范文第1篇

1.进程及通信类型

1.1系统中进程的划分

系统中的进程是装入内存并准备执行的程序,每个进程都有私有的虚拟地址空间,由代码、数据以及它可利用的系统资源(如文件、管道等)组成。对Windows操作系统而言,多用户多任务是其最基本的要求,从而多进程是其基本特征。进程间共同完成特定任务时分工、协作是必然的,从此角度出发,可将系统中的进程分为两类:客户方进程和服务方进程[1]。客户方进程是指发起通信的进程或应用程序,而服务方进程是指接受并应答发起方信号的进程。此种分类对所有的通信双方都适用,但无益于软件开发。另一种分类方法是从软件开发的角度出发,可将系统中的进程分成已方进程、系统进程和他方进程[2]。已方进程即由软件开发方开发的应用程序进入系统后形成的进程,而软件开发方开发的应用程序以外的应用程序进入系统后形成的进程称为他方进程,而系统进程则是由Windows操作系统所提供的进程。第三种分类方法是以进程所处的位置为出发点,可分为本地进程和远程进程[3]。

1.2进程间的通信类型及特点

根据进程分类结果,可以得到进程间的通信类型:

Ⅰ、本地已方进程之间的通信;

Ⅱ、本地已方进程和远程已方进程间的通信;

Ⅲ、本地已方进程和本地他方进程间的通信;

Ⅳ、本地已方进程和远程他方进程间的通信;

对于第一种进程间通信,通信双方进程的彼此都来自于同一软件开发方,进程间通信的协议、数据和内容都可由软件开发方在软件设计阶段统一加以考虑。软件开发方在软件设计阶段充分考虑到进程间通信的需求,进而主动采取某种较为成熟的通信实现方式来分别设计实现进程间通信的客户端和服务器端,从而形式进程间通信的既成的“默契”,这种“默契”实际上是在软件设计阶段就取得了,在此将这种通信模式称为“有意识”型。

第二种进程间的通信方式,尽享了第一种进程间通信方式的便利,但不在开发时选择通信的方式上受到了一定的限制,是一种有约束的“有意识”型模式。

第三种和第四种进程间的通信方式中,通信双方来自完全不同的软件开发方,由此很难在事先达成类似第一、二类型进程间的通信的那种“默契”,通信过程中,通信双方往往没有既定的客户端和服务器端,服务器端完全不知道客户端进程的存在,也不清楚客户端要与之实现通信所使用的某种特定的协议的内容,服务端只能对符合自己格式和类型的客户请求作出响应,故此这种通信模式是“无意识”型[2]的,不管进程是否在本地,通信的双方都只是按自己认定的规则做事,在本地按既定的规则做,不在同一主机也按符合远程通信的既定规则工作。

上述的分类方式有助于开发者选择不同的通信方式,但不足以反映通信时进程的特点。因此,关于进程间的通信又常根据进程通信时信息量大小的不同分类,进程间传递少量的控制信息将其通信称为低级通信,而传递大批数据信息时,将其称为高级通信。

低级通信主要用于进程之间的同步、互斥、终止、挂起等等控制信息的传递。高级通信主要用于进程间数据块的交换和共享。

2进程间通信方式及不同通信类别下的选用

2.1进程间通信方式及特点

Ⅰ、文件映射。文件映射(Memory-Mapped Files)能使进程把文件内容当作进程地址区间一块内存那样来对待。因此,进程不必使用文件I/O操作,只需简单的指针操作就可读取和修改文件的内容。但文件映射只能用于本地机器的进程之间,不能用于网络中,而开发者还必须控制进程间的同步。

Ⅱ、共享内存。Win32 API中共享内存(Shared Memory)实际就是文件映射的一种特殊情况。进程在创建文件映射对象时用特定的地址来代替文件句柄(HANDLE),就表示了对应的文件映射对象是从操作系统页面文件访问内存,其它进程打开该文件映射对象就可以访问该内存块。由于共享内存是 用文件映射实现的,所以它也有较好的安全性,也只能运行于同一计算机上的进程之间。

Ⅲ、WM_COPYDATA消息。WM_COPYDATA是一种很好的数据传输方式。当一个应用向另一个应用传送数据时,发送方只需使用调用SendMessage函数,参数是目的窗口的句柄、传递数据的起始地址、WM_COPYDATA消息。接收方只需像处理其它消息那样处理WM_COPY DATA消息,这样收发双方就实现了数据共享。它的使用非常简单,在底层实际上是通过文件映射来实现的。它的缺点是灵活性不高,并且它只能用于Windows平台的单机环境下。

Ⅳ、剪贴板。剪贴板(Clipped Board)实质是Win32 API中一组用来传输数据的函数和消息,为Windows 应用程序之间进行数据共享提供了一个中介,Windows已建立的剪切(复制)-粘贴的机制为不同应用程序之间共享不同格式数据提供了一条捷径。但剪贴板只能在基于Windows的程序中使用,不能在网络上使用。

Ⅴ、动态数据交换。动态数据交换(DDE)是使用共享内存在应用程序之间进行数据交换的一种进程间通信形式。DDE交换可以发生在单机或网络中不同计算机的应用程序之间。开发者还可以定义定制的DDE数据格式进行应用程序之间特别目的IPC,它们有更紧密耦合的通信要求。大多数基于Windows的应用程序都支持DDE。

Ⅵ、对象连接与嵌入。应用程序利用对象连接与嵌入(OLE)技术管理复合文档(由多种数据格式组成的文档),OLE提供使某应用程序更容易调用其它应用程序进行数据编辑的 服务。例如,OLE支持的字处理器可以嵌套电子表格,当用户要编辑电子表格时OLE库可自动启动电子表格编辑器。当用户退出电子表格编辑器时,该表格已在原始字处理器文档中得到更新。在这里电子表格编辑器变成了字处理器的扩展,而如果使用DDE,用户要显式地启动电子表格编辑器。同DDE技术相同,大多数基于Windows的应用程序都支持OLE技术。

Ⅶ、管道。管道(Pipe)是一种具有两个端点的通信通道:有一端句柄的进程可以和有另一端句柄的进程通信。管道可以是单向即一端是只读的,另一端点是只写的;也可以是双向的一管道的两端点既可读也可写。

管道有两种,一种是匿名管道(Anonymous Pipe),它用于在父进程和子进程之间,或同一父进程的两个子进程之间传输数据的无名字的单向管道。匿名管道是单机上实现子进程标准I/O重定向的有效方法,它不能在网上使用,也不能用于两个不相关的进程之间。另一种管道是命名管道,命名管道(Named Pipe)是服务器进程和一个或多个客户进程之间通信的单向或双向管道。命名管道提供了相对简单的编程接口,使通过网络传输数据并不比同一计算机上两进程之间通信更困难,不过如果要同时和多个进程通信它就力不从心了。

Ⅷ、邮件槽。邮件槽(Mailslots)提供进程间单向通信能力,任何进程都能建立邮件槽成为邮件槽服务器。其它进程,称为邮件槽客户,可以通过邮件槽的名字给邮件槽服务器进程发送消息。进来的消息一直放在邮件槽中,直到服务器进程读取它为止。一个进程既可以是邮件槽服务器也可以是邮件槽客户,因此可建立多个邮件槽实现进程间的双向通信。

Ⅸ、动态连接库。Win32动态连接库(DLL)中的全局数据可以被调用DLL的所有进程共享,这就又给进程间通信开辟了一条新的途径,当然访问时要注意同步问题。虽然可以通过DLL进行进程间数据共享,但从数据安全的角度考虑,我们并不提倡这种方法,使用带有访问权限控制的共享内存的方法更好一些。

Ⅹ、远程过程调用。Win32 API提供的远程过程调用(RPC)使应用程序可以使用远程调用函数,这使在网络上用RPC进行进程通信就像函数调用那样简单。RPC既可以在单机不同进程间使用也可以在网络中使用。由于Win32 API提供的RPC服从OSF-DCE (Open Software Foundation Distributed Computing Environment)标准。所以通过 Win32 API编写的RPC应用程序能与其它操作系统上支持DEC的RPC应用程序通信。使用RPC开发者可以建立高性能、紧密耦合的分布式应用程序。

Ⅺ、NetBios函数[4]。Win32 API提供NetBios函数用于处理低级网络控制,这主要是为IBM NetBios系统编写与Windows的接口。除非那些有特殊低级网络功能要求的应用程序,其它应用程序最好不要使用NetBios函数来进行进程间通信。

Ⅻ、Windows套接字(Windows Sockets)。Windows套接字规范是以U.C.Berkeley大学BSD UNIX中流行的Socket接口为范例定义的一套Windows下的网络编程接口,是跨平台的协议,现在通过Sockets实现进程通信的网络应用越来越多。另外高版本的 WinSock 不仅支持TCP/IP协议,而且还支持其它协议(如IPX)。Sockets的唯一缺点是它支持的是底层通信操作,使用是十分繁琐,这使得在本地进程间进行简单数据传递较为不便。

2.2 第一种通信进程类型间通信的实现方法

所有的通信,对于通信的双方均需要事先达成通信协议方可实现,对于第一种通信类型的进程间的通信,通信的双方是同一开发者,取得“默契”条件成熟,实现较易。较其方式也最多。主要有以下几种: 文件映射、共享内存、WM_COPYDATA消息、剪贴板、动态数据交换、对象连接与嵌入、匿名管道、动态连接库、NetBios函数、Windows套接字等。

2.3第二种通信进程类型间通信的实现方法

虽然与第一种一样有取得“默契”的先天条件,但由于通信的双方处于不同的主机中,且由于Windows操作系统的进程间的保护机制,会造成执行时发生数据存取的保护性错误(Access Voilaton),故通信的方式受到一定的限制。此种有意识模型的通信方式主要有以下几种:文件映射、WM_COPYDATA消息、动态数据交换、对象连接与嵌入、命名管道、邮件槽、Windows套接字(Windows Sockets)等。

2.3第三种通信进程类型间通信的实现方法

本种通信进程类型中的通信双方虽然处于同一主机中,但由于开发者的不同,双方只能根据公共的规则和协议实现各自的开发。故其通信方式亦受到一定的约束,其常用的方式有如下几种:动态数据交换、对象连接与嵌入、命名管道、邮件槽、Windows套接字等。

2.4第四种通信进程类型间通信的实现方法

这种通信进程类型中的通信双方间的通信所受的制约最多,既要考虑到进程间远程特性,又要考虑到双方的开发者“不识”,故其通信方式在选择时最为谨慎,常用的通信方式有:命名管道、邮件槽、Windows套接字等。

3.结语

系统进程繁多,Wiondows32下为进程间提供的通信方式繁杂,在软件开发的过程中,对不同类型进程间的通信方式选用适当的通信方式,既能适当减少开发的工作量又能保证所开发软件的健壮性和可靠性,同时能大大提高了通信的灵活性。在实际开发中,将几种模式的进程间通信的实现方法结合起来加以应用,即可实现各类进程间的数据交换。

参考文献

[1]新编WINDOWS API参考大全编写组.新编WINDOWSAPI参考大全[M].北京:电子工业出版社,2005.

[2]梁庚,白焰. Windows下进程间通信方式探讨[J] 微型电脑应用 2006,(22):44,58~60.

[3]求是科技 王洪涛编著. 深入剖析Visual C++[M].北京:人民邮电出版社,2004.

[3]David Bennet著.徐军译.VC++5开发人员指南[M].北京:机械工业出版社,1998.

[4]肖红伟.VC++6.0编程实效百例[M].北京:人民邮电出版社,2002.

进程间通信范文第2篇

关键词:进程间通信(IPC);Linux;消息总线

1 消息总线设计需求

D-Bus消息总线是面向桌面系统设计,接口丰富,但占用资源较多。重新设计的消息总线将满足占用系统资源少,且可以满足路由器软件系统的消息转发需求。消息总线(Message Bus,以后简称M-Bus)模块作为路由器软件系统的基础软件模块,M-Bus被设计成了一个为路由器操作系统各应用程序提供模块间通信的唯一上层平台。M-Bus自身被抽象化成一个提供进程间通信方法的函数功能库,负责路由器软件系统各模块间的消息转发和消息广播,实现的方式是向整个系统提供C的API接口以供其他应用程序调用。M-Bus底层是使用套接字、信号量、管道等Linux基本进程间通信方法进行封装。M-Bus在消息处理方式是消息的直接转发。消息的直接转发使用命名管道来实现,参与通信的各个进程直接调用M-Bus库函数,各个应用程序根据自身注册到消息总线上的消息处理函数,做出下一步的动作。

2 消息总线总体设计

消息总线被设计成了一个为路由器操作系统各应用程序提供模块间通信的唯一上层平台。消息总线自身被抽象化成一个提供进程间通信方法的函数功能库,负责路由器软件系统各模块间的消息转发和消息广播,实现的方式是向整个系统提供C的API接口以供其他应用程序调用。消息总线底层是使用套接字、信号量、管道等Linux基本进程间通信方法进行封装。消息总线在消息处理方式是消息的直接转发。消息的直接转发使用命名管道来实现,参与通信的各个进程直接调用消息总线库函数,各个应用程序根据自身注册到消息总线上的消息处理函数,做出下一步的动作。消息总线包括以下三个子模块:(1)消息总线的接口集合,包括消息的发送、消息的接收、消息发送者与接收者的登记等一系列消息总线能够提供的API函数。(2)消息总线的守护进程。(3)消息总线内部工作处理,为上层API函数提供基础。路由器的各应用程序通过调用消息总线的API函数来使用消息总线的功能。消息总线提供了本地资源初始化、销毁本地资源、注册、卸载、发送消息、接收消息、登记消息处理等API函数。消息总线中所定义的消息,是进程间传递数据的载体,消息的定义遵循以下原则:(1)每个消息都有自身的名字,消息的名字表示要发送的消息是什么命令。(2)消息的名字在系统中是唯一的。(3)系统能处理消息的种类的能力是有限的。各个模块收到消息后会跟据消息的名字执行相应的处理函数,(4)消息具有统一定义的数据结构,包括消息头、携带数据、消息上下文(Context)。消息的名字(也可称为消息的类型)作为消息头中的一个数据域的形式存在。

3 消息总线数据结构的设计

消息的自身是数据传递的载体并且消息具有相应的结构。消息结构组织分为两类:一类是各模块之间通信的消息结构;另一类是各模块本地维护的消息结构。

其中,消息头被定义成各模块间通信的唯一结构,各模块间的通信是通过解析消息头来提取数据,从而实现进程间的通信。而各模块本地维护的消息结构称之为消息上下文,每个模块都会有自身的消息上下文,由各个模块自己组织与管理,与外界隔离。图1描述了消息头的数据结构:

图1 消息头数据结构示意图

消息头中包含以下定义内容:(1)消息的发送者:定义该消息是由哪个模块发送的,路由器所有模块的名称均用宏定义。(2)当前进程PID:该消息的发送进程的PID。(3)消息的名字:该消息发的是什么指令。(4)消息的同步:当接收进程收到消息后需要做反馈操作,回复发送进程进行收到确认。如果不做同步操作则不需要回复。(5)数据长度:消息所携带的数据长度。(6)携带数据起始位:所携带数据的起始位地址。起始位地址加上所携带数据的长度就可以表示该消息携带的所有数据,即消息的消息体。作者称各模块自身维护的消息为本地消息,描述本地消息的数据结构称为消息上下文,路由器软件系统中每个模块(每个应用程序)自身只能存在一个消息上下文。设计消息上下文的原因在于是想把使用消息总线的所有数据与操作方式都组织到一起,然后封装成统一的结构来进行描述。每个应用程序注册到消息总线上的时候,都会生成自身的消息上下文。图2描述了消息上下文的数据结构定义。

图2 消息上下文数据结构示意图

消息上下文中包括了以下内容:(1)注册到消息总线上的应用程序自身名字。名字由字符串表示,系统中所有的应用程序名字均使用宏进行定义。(2)当前注册到消息总线上的进程ID。进程ID用于表示消息总线使用者的身份。(3)当前接收消息的文件描述符。当一个进程新注册到消息总线上时,该文件描述符设置为-1。当该进程参与消息的发送或接收时,该文件描述符表示文件操作句柄。(4)进程退出函数指针,typedef void(*pf_user_exit)(void)。当一个已在消息总线上注册过的进程想要从消息总线上卸载时,调用自身定义的退出函数实现退出。(5)消息处理函数指针。当应用程序收到消息时解析该消息,根据解析到的消息名字调用相对应的消息处理函数。当应用程序向消息总线上注册时,必须注册对应消息的处理函数。(6)默认消息处理函数指针。(7)消息头。

参考文献

[1]Bird Intern Articles on Routing Software Openwrt[M].Hephaestus Books,2011:115-120.

[2]Jim Brown.Articles on Routers[M].Hephaestus Books,2011:45-59.

进程间通信范文第3篇

关键字:分布式系统;进程间通信;通信方法

中图分类号:TP31文献标识码:A文章编号:2095-2104(2012)01-0020-02

Research on Process Communication Realized by Distributed System

WANG Lichuang, ZHOU Zengming,

(1. Hebei Far East Harris Communications Company Ltd,Shijiazhuang 050000, China)

Abstract: Using inter-process communication in application programming design is a good method, which can make full use of system resources as well as improving the efficiency. The Internet and distributed computing technology develop fast recent years, as a result, more and more application systems applied to the network aspect, especially to the distributed environment. But progresses communication are usually contained in the network and the distributed programming design, therefore, the communication mechanism among processes becomes even more important. This paper focuses on the overview of distributed system and process communication mechanism, also the applications and characteristics of the multilayer distributed system, make a conclusion by the applications of distributed system, can greatly improve the computer efficiency. With distributed system, computer users can get data by transparent access , this also could improve computer performance and reliability. The distributed system would greatly improve the service performance itself, and meet the needs of the customers more perfect in future.

Keywords: Distributed systems; Inter-Process Communication; Communication methods

前言

从上个世纪四五十年代,伴随着计算机的产生和发展,计算机的处理系统也在进一步地发展。五十年代,计算机是通过串行处理,一次进行一个作业直到结束,这种处理是需要操作员通过操纵台进行操作,普通用户无法访问。六十年代,以一组相似的作业进行批量操作处理,进步在于减少了计算机的空闲时间。七十年代,进一步发展,产生了分时系统,进一步提高了计算机的利用率。八十年代,则主要是个人计算机发展的阶段,相应的处理器是用户个人专用的。分布式系统随着分时系统的进一步发展和网络技术的提高成为了现实。用户在完成任务时,分布式系统提供了对尽可能多的计算机能力和数据的透明访问,并且提高了性能和可靠性。

1 分布式系统概述

分布式系统是指是建立在网络之上的软件系统。其特点是具有很高的透明性和内聚性。分布式系统是一个相对新的领域,与顺序计算相比,并行的、并发的和分布式的计算包括多个PE见的集体协同动作,这些属于在范围上相互覆盖,可以互换使用。

并行式的是指从一个单一控制现成对数据集的lockstep动作。在并行计算机级别上,单指令流多数据流(SIMD)计算机就是一个使用多个数据处理单元在多个数据项上同时进行相同或相似操作的例子。

并发式的是指,一些动作可以任意次序执行。比如,可以在较高级别上和多指令流、多数据流(MIMD)并行计算机上进行部分独立的操作。

分布式的则指计算的成本或性能取决于控制和数据的通信。

集中式的是指一个系统的部件局限在一个地方,分散式的则指系统的部件不在一个地方,部件之间或者不存在或只存在有限的合作,或者存在紧密的合作。网络式的是指当一个分散式系统不存在或只存在有限的合作的情况,否则被称为分布式的,即在不同地方的部件之间存在着紧密的合作。分布式系统通常以控制、数据、硬件这三个维度进行检验。

于是,分布式控制+分布式硬件+分布式数据=分布式系统。

2 进程间通信概述

进程通信是指进程间的信息交换,是分布式系统的核心。进程间进行消息传递需要支持两个消息通信语,分别是发送(send)和接收(receive)。分布式系统的通信是以底层网络提供底层消息传递机制为基础的。现代分布式系统中的进程数量达上百万个,替代计算机网络的原始通信功能的技术已是必然趋势。

2.1分布式系统进程通信

分布式应用系统可以直接使用网络操作系统所提供的编程接口。但是这种方式难以使分布做到透明化,对于编写大规模分布式应用程序不适用。现在常用的编程平台是中间件,中间件系统提供多种通用的服务,通过计算机网络进行的底层消息传递的隐藏可以通过提供高层通信动能来实现,以便访问的透明性。支持通信的具体方式,随中间件系统向用户和应用程序提供的分布模型的不同而形成较大的差异,例如RPC,RMI和消息队列。

2.2进程通信中的持久性和同步性

在分布式系统中,消息的发送者和接受者可能在同时运行中也可能不在同时运行中,所以进程通信分为持久通信和暂时通信,持久通信需要传输的消息在提交之后由通信系统来存储,直到将其交付给接收者为止。持久通信要求存在持久保存消息的消息服务器,消息保存在硬盘中,消息服务器给发送者和接收者起到桥梁作用,因此,发送消息的应用程序不必在提交消息后保持运行。同样,要接收消息的应用程序在消息提交到消息服务器时也可以不处于运行状态。

暂时通信只在发送和接收消息的应用程序运行期间存储消息,如果路由器无法将消息递送到下一个路由器或者接收者,消息将会被简单地丢弃。例如传输层通信服务都仅仅提供暂时通信。

持久通信和暂时通信各有优缺点.暂时通信有很高的效率, 实时性强, 而且不需要额外的硬件支持.然而, 暂时通信很难做到地域扩展,暂时通信的容错能力也较弱,系统发生故障时,难于将故障屏蔽并启动恢复过程.持久通信能克服暂时通信的缺点。分布式系统由局域网环境向互联网环境扩展过程中,持久通信就能发挥重大作用.在不可靠的互联网中,可能由于网络故障或者进程故障导致访问受到限制,并且很难做到发送应用程序和接收应用程序同时处于工作状态,持久通信牺牲通信延时,但可以保证消息可靠接收.持久通信的另一个优点是,系统存在坚固存储器,容易屏蔽故障及从故障中恢复出来。

3 分布式系统的应用和标准

分布式系统应用于许多不同的应用中,在众多的应用中使用分布式系统要明显优于其他系统,特别是在单机处理和共享存储器多处理机方面,以下列举一些具体应用:

3.1容错应用

由于每个PE的自治性特点,分布式系统更具有可靠性,可以使机器的某一部件出现故障时不影响其他部件的正常功能。

3.2并行和高性能应用

并行应用原则上可以在共享存储器多处理机上运行,但是,共享存储器系统无法很好地扩大规模已包括大量的处理机。高性能计算和通信(HPCC)应用一般需要一个可以伸缩的设计,这种设计正是由分布式处理决定。

3.3固有的分布式应用

许多应用是固有分布式的,这些应用不是批量模式二是突发模式的,比喻有事务处理和Internet Java小程序。这些应用的性能取决于事务相应时间或每秒完成事务量即吞吐量,并非一般多处理机所用的执行时间。

分布式系统对于一组用户来说,具有一个特别的应用成为计算机支持的协同工作或者群件,支持用户协同工作。另一个应用是通过物理的分布式网络进行电子会议即分布式会议。

适合于分布式系统的通信机制有:并行度,进程网络拓扑,程序验证的复杂性,系统死锁,通信规约的复杂度,缓冲区。

由于在不同的平台上就可以获得不同的多样的应用,比如在工作站,PC,局域网和广域网。用户希望能超出他们PC的限制以获得更广泛的特性、性能和功能等。不同环境和网络下的互操作性变得越来越重要,为了达到这一目标,用户需要在一个标准的分布式环境中,使所有的资源和系统都可以利用。

多层分布式应用体系中,系统资源可以被统一管理和使用,用户可以通过网格门户透明地使用整个网络资源,多层分布式体系有安全性,因其中间层隔离了客户直接对数据服务器的访问,保护了数据库的安全。还有稳定性,易维护,相应快速、系统扩展灵活等特点。对于多层分布式系统的开发和应用,主要是针对开发环境、应用程序的集成和应用程序的配置三个方面的技术开发。目前多层次系统的开发的两种规范是:用于Windows 平台的COM+和用于跨平台的CORBA两种。其应用主要是在三个层次分别是:表示层,业务逻辑层,数据存储层。

4 结语

进程通信是分布式系统的核心,是开发分布式应用程序和研究分布式系统的基础。分布式系统的应用和实现为计算机进步又提升了一个大的空间,随着科学技术的不断进步,分布式系统仍需要不断改进和完善,最终以满足用户的需要,提供更方便快捷的操作系统,进一步助推科技进一步发展。本文主要从对分布式系统的介绍,通信进程的概述和分布式系统在进程间通信的实现展开讨论。相信随着科技的进步分布式系统会提高服务性能,更好的满足客户的需求。

参考文献:

[1]王宇,王志坚《基于志愿计算模式的分布式水文计算》,《水利学报》,2007年10月增刊.

[2]徐高潮,《分布计算系统》,北京:高等教育出版社, 2004 .

[3]陆丽娜等译 ,《分布式操作系统》北京:电子工业出版社,1999.

[4](美)特尼博姆 等著,辛春生等译,《分布式系统原理与范型》清华大学出版社2008.6.

进程间通信范文第4篇

关键词:Android;AIDL;进程通讯

操作系统中,多个进程间进行通讯、共享资源实现系统功能平台,是非常基础和重要的功能应用;同时,进程通讯也是操作系统内核的重要功能部分。Linux操纵系统中,进程通讯一般使用传统的IPC(Inter-Process Communication,IPC)模式,且IPC模式实现了共享内存、管道、消息队列和socket等等,虽然IPC模式广泛使用,但IPC模式中UID/PID数据是由应用程序填入,存在着可靠性差,容易被篡改,难于维护等问题。

AIDL(Android Interface Definition Language)是Android系统自定义的接口描述语言,是Android平台中实现进程间通讯方式一种,属轻量级通讯机制,有着实现简单、效率较高等优点。

1 AIDL实现原理及过程

AIDL语言属于系统级原语,但语法结构和Java语言非常相似,AIDL中主要用于定义访问接口,无实现过程。与Java不同的是,AIDL允许定义函数参数传递的方向,AIDL中支持三种方向:in,out,inout。

标识为in的参数将从调用者传递到远程服务中;

标识为out的参数将从远程服务传递到调用者中;

标识为inout的参数将先从调用者传递到远程服务中,再从远程服务返回给调用者。

ADIL实现过程一般按以下步骤:(1)创建AIDL接口描述文件;(2)通过继承android.os.Iinterface接口实现远程服务AIDL接口的Java接口;(3)绑定和使用远程服务;(4)客户端调用。

AIDL通讯案例中,服务端一般由一个AIDL文件和一个IService实现接口及Service实现类组成,其中IService接口用于实现AIDL所定义的访问方法,且IService必须是android.os.Iinterface子接口,Service实现类则是AIDL接口具体的实现类。

1)定义如下AIDL文件如下:

interface IService {

int getAccountBalance();

int getCustomerList(in String branch, out String[] customerList);

}

2)Iservice接口的实现

在实现AIDL接口的Service接口其内部结构由三部分组成,1)内部静态抽象类Stub,Stub类及其子类在整个AIDL通讯中非常重要,是用于实现AIDL接口的实现类,Stub必须是Android.os.Binder的子类及IService的实现类。2)内部静态类Proxy,Proxy类属于是向远程服务提供调用接口类。3)是IService中实现的AIDL访问接口方法。Iservice接口部分代码如下所示:

public interface IService extends android.os.IInterface

{

public static abstract class Stub extends android.os.Binder {//Stub 内部静态抽象类…..

private static class Proxy implements com.lifeblood.ITestService

/内部静态类Proxy /………..

public int getAccountBalance();

public int getCustomerList(in String branch, out String[] customerList);

//现的AIDL访问接口方法

3)TestService类的实现

TestService实现类,是Android中普通Service类Android.os.Service子类,是实现AIDL描述接口的重要实现类,但其实现过程有点特殊,是通过定义ItestService.Stub类型成员变量,实现Iservice接口中调用方法,也就是AIDL中定义的描述接口方法。

4)Activity类中启动Service服务

本案例中Service只是提供远程服务,无需在本地Activity中进行访问,所以使用Intent类启动Service即可,代码结构如下: Intent service = new Intent(this, TestService.class);

startService(service);

5) AndroidManifest.XML中的配置

AndroidManifest.XML文件的配置非常重要,远程服务时其他进程访问定位到服务,就是通过AndroidManifest文件的配置名称进行定位,其Service段配置如下:

6)客户端进程调用

客户进程调用时与JNDI方式相似,通过实现ServiceConnection接口绑定远程服务,获取Service对象,从而实现调用,在客户端实例中也需拷贝AIDL接口文件。

2 测试运行

程序运行步骤如下:首先运行TestService服务端;再运行AIDLClient客户端;点击绑定连接AIDL获取Service服务,并显示调用信息。效果如图1所示。

3 结束语

进程间通信范文第5篇

操作系统;文件系统;功能调用

1.问题的提出及论文的目的

在Windows7环境下,创建一个控制台进程,此进程包含n个线程。用这n个线程来表示n个读者或写者。每个线程按相应测试数据文件的要求进行读写操作。用信号量机制分别实现读者优先和写者优先问题。

通过分析并实现经典的“读者-写者”问题,巩固对线程及其同步机制的学习效果,加深对相关基本概念的理解,并让读者了解如何将基本原理和实际设计有机的结合。

2.设计思路

可以将所有读者和所有写者分别存于一个读者等待队列和一个写者等待队列中,每当读允许时,就从读者队列中释放一个或多个读者线程进行读操作;每当写允许时,就从写者队列中释放一个写者线程进行写操作。

读者优先。读者优先指的是除非有写者在写文件,否则读者不需要等待。所以可以用一个整数变量Read count记录当前的读者数目,用于确定是否需要释放正在等待的写者进程(当Read count=0时,表明所有的读者读完,需要释放写者等待队列中的一个写者)。每当一个读者开始读文件时,必须修改Read count变量。因此需要一个互斥对象mutex来实现对全局变量Read count修改时的互斥。

另外,为了实现读-写互斥,需要增加一个临界区对象Write。当写者发出写请求时,必须申请临界区对象的所有权。通过这种方法,可以实现读-写互斥,当Read count=1时(即第一个读者到来时),读者线程也必须申请临界区对象的所有权。

当读者拥有临界区的所有权时,写者阻塞在临界区对象Write上。当写者拥有临界区的所有权时,第一个读者判断完”Read count==1”后阻塞在Write上,其余的读者由于等待对Read count的判断,阻塞在mutex上。

写者优先。写者优先与读者优先相类似。不同之处在于一旦一个写者到来,它应该尽快对文件进行写操作,如果有一个写者在等待,则新到来的读者不允许进行读操作。为此应当填加一个整形变量Write count,用于记录正在等待的写者的数目,当Write count=0时,才可以释放等待的读者线程队列。

为了对全局变量Write count实现互斥,必须增加一个互斥对象mutex3。

为了实现写者优先,应当填加一个临界区对象read,当有写者在写文件或等待时,读者必须阻塞在read上。

读者线程除了要对全局变量Read count实现操作上的互斥外,还必须有一个互斥对象对阻塞read这一过程实现互斥。这两个互斥对象分别命名为mutex1,mutex2。

以上内容很清楚的讲述了进程间通信之经典问题—“读者-写着”问题的本质,并且提出了实现的方法,可以帮助读者学好操作系统这门核心的计算机专业课程。

[1]汤子瀛.计算机操作系统[M].西安:西安电子科技大学出版社,2011.08

[2]特南鲍姆.现代操作系统[M].北京:机械工业出版社,2002.01

进程间通信范文第6篇

关键词:网络通信;跨平台;中间件;ACE

中图分类号:TP311.13 文献标识码:A 文章编号:1007-9599 (2011) 18-0000-01

Multi-Platform Communication Middleware Research and Implementation

Li Fengzhong,Mu Bin

(School of Software Engineering,Tongji University,Shanghai 201804,China)

Abstract:Software development for heterogeneous networks,different platform communication is becoming more complex,even with substantially similar function,but also the need for different types of networks,different platforms,communication modules,respectively.This paper presents a cross-platform middleware solutions for communication,through IPC mechanisms and the use of ACE,a development,multiple use,for cross-platform communication provides a reasonable solution.

Keywords:Network communications;Multi-platform;Middleware;ACE

一、前言

为不同平台提供网络通信正变的日益繁琐。不同操作系统之间,比如Windows和Linux之间,比如不同的开发平台之间,比如.Net平台与J2EE平台,其通信功能的开发往往要针对不同情境分别开发,且开发的功能与实现方式基本类似,浪费资源,增长了开发周期。

本文介绍了一种能够提供跨平台通信的网络中间件。通过共享内存机制实现了中间件与应用软件之间的通信,通过ACE高度封闭的跨操作系统网络通信接口。

共享内存技术是一种广泛应用于操作系统内进程间通信的机制。

相较于消息、管道、邮槽等其他进程间通信方法,共享内存的最大的优点在于其极高的效率[1]。

ACE全称为Adaptive Communication Environment,是一个一个实现了并发通信软件的核心设计模式的、免费的、开放源代码的、面向对象软件框架。ACE可用于开发复杂的、并发的分布式系统,来构架网络服务器,可以很简单地实现跨平台、可重用等要求。

二、设计详情

由下向上,本程序按层次划分为网络运输层、可靠性保障层、进程间通信层,不同层之间通过定义好的接口相互通信,分层结构如下图所示。

网络层提供了基本的点到点、不可靠数据传输服务;可靠性保障层在网络层基础之上,提供了同步与异步的、可靠的通信层功能;而进程间通信层在可靠性保障层之上,实现了数据在工控程序与通信程序之间的通信[2]。

三个层次之间使用的报文格式如下图所示:

(一)网络通信层

本层提供的网络功能为最基本的数据传输功能,使用ACE完成通信功能。

(二)可靠性保证层

因为网络通信层提供的是不可靠的数据传输服务,因此可靠性保障层提供的主要功能便是保证数据可靠传输。

(三)进程间通信层

进程间通信层使用共享内存实现数据的跨进程交互。

三、结语

通过共享内存高效完成中间件与应用程序的通信,通过ACE完成跨平台代码编写与网络通信功能的实现,本解决方案很好的完成了跨平台网络通信功能,提高了相关系统的开发效率。

参考文献:

[1]刘磊,李连彬.Windows系统网络通信层性能及方法研究[J].吉林大学,计算机应用,2009,12

进程间通信范文第7篇

关键词: 模块通信; 事件模型; 软件框架; 面向对象; Qt

中图分类号:TP391 文献标志码:A 文章编号:1006-8228(2012)11-16-03

Design and implementation of software communication framework based on uniform event model

Pang Rui, Lv Da, Chen Ke

(SINOPEC Geophysical Research Institute, Nanjing, Jiangsu 211103, China)

Abstract: Targeted on module communication requirement of modern software system, a solution to software communication framework is proposed. By analyzing communication requirement in module development, uniform event model is constructed, and software framework for module communication is designed. Finally, by using Qt, a communication framework is realized. Using the framework can reduce module complicacy and shorten development period of communication. Furthermore, software maintenance is improved, and software transplant benefits.

Key words: module communication; event model; software framework; object-oriented; Qt

0 引言

随着计算机技术的飞速发展,各类软件系统为了满足不断变化的用户需求,提供的功能越来越多,其软件规模日益庞大,实现复杂度也越来越高。在现代软件系统中,对复杂的业务需要进行层次划分,将业务功能相对模块化,模块具备高内聚低耦合的特性,通过模块间的协同工作来提供复杂的软件功能[1]。软件模块协同工作的基础是在模块间可以传递信息数据,根据业务划分不同,可以在一个进程中只包含一个模块,通过进程间模块通信协同工作,也可以在一个进程中包含多个模块,通过进程内模块通信协同工作。那么,建立一个高效统一的进程间、进程内事件通信机制,才能保证各个模块间可靠的协作关系,降低软件系统通信复杂度,提高开发效率。

1 软件模块的通信需求分析

面向不同的行业应用领域,软件模块的通信需求是不同的。在专家决策系统中,模块间需要借助通信对同一数据进行联动操作分析;在游戏软件中,模块间需要利用通信对用户交互操作进行协同处理;在计费软件中,模块间需要传递各种费用数据。各类软件系统,其共同点是,需要在模块间传递特定的事件通知或数据信息,以协同完成工作。根据不同软件系统的设计,软件模块的通信可以分类为进程间通信和进程内通信。

⑴ 进程间通信

软件模块分散在不同的进程中,模块需要通过进程间的通信手段来传递事件通知和数据信息。通常操作系统提供的进程间通信(IPC)方式主要有:信号、信号量、消息队列、管道、共享内存、套接字等。其中,信号、信号量、消息队列可以用于传递事件通知,管道、共享内存可以用于传递数据信息,套接字的应用更为灵活,可以同时用于事件和数据的传递[2]。此外,在Windows操作系统中,还可以利用窗口消息来传递事件。虽然操作系统提供了多种进程间通信手段,但是大都与操作系统底层接口紧密相关,如果直接使用,在兼容性和跨平台方面有所不足。

⑵ 进程内通信

软件模块集中在一个进程中,模块通过进程内的通信手段来传递事件通知和数据信息。有别于进程间通信中各个模块受进程空间隔离,在同一进程内的模块可以共享进程的内存数据,可以相互调用模块接口。因此,进程内通信方式比较灵活,可以引用模块的指针来访问模块,也可以向模块发消息。考虑到软件开发的规范,需要对进程内通信形式进行统一约定。

2 软件通信框架设计

2.1 统一的事件模型设计

软件通信的主要任务就是在模块间传递数据。其首要问题是如何对要传递的数据进行规范描述,我们必须建立一个适用于进程内,同时也适用于进程间传递的统一事件模型。这个事件模型并不是具体传递的事件数据,它是一个规范标准,一个模板,所有参与通信的模块必须围绕这个事件模型,定义自己需要接收或发送的具体事件,最终模块间传递的是这些已定义的事件,虽然它们代表的信息各不相同,但都是基于同一个事件模型,有着相同的规范描述。图1描述了进程间和进程内事件传递的模型结构。

图1 事件模型结构图

一个事件模型需要包含如下基本信息。

事件标识ID:一个整数,表明这个事件的含义;

发送模块标识ID:一个整数,标识是从哪个模块发送的事件;

进程间通信范文第8篇

关键词 网络通信;UDP二次封装;共享内存;进程间通信

中图分类号TN92 文献标识码A 文章编号 1674-6708(2011)55-0181-02

1研究背景

磁浮仿真系统大致可以为分3个层次,底层是仿真子系统的仿真管理计算机,中间层是仿真支撑服务器,上层是工作站仿真计算机。所有环境仿真设备通过以太网与底层子系统的仿真管理计算机相连,仿真管理计算机对其仿真子系统进行统一管理,它将子系统仿真设备的工况信息实时向上推送。仿真支撑服务器与所有底层子系统管理计算机和上层工作站均有通信需求,是报文收发的中转站,它将、工作站及其执行结果的信息记入数据库备查,或用于数据分析。上层工作站用于集成管理底层的子系统,它注入故障下达测试命令到底层子系统管理计算机并等待应答。此外,底层子系统管理计算机之间也互相传递信息。这些计算机中仿真系统在处理接收和发送数据上的工作大多是相同的,如果能够简化它们在数据通信上的工作,将对系统的设计和效率有很大的提高作用。网络通信方案的设计,即可将系统中各模块处理网络通信的部分抽取出来,封装成一个相对独立的模块。

2影响因素分析

磁浮仿真系统中底层管理计算机上运行的仿真软件是不同编程语言实现的,各自重新构建通信接口有困难,底层、中层、上层不同计算机之间的通信要求也各异。通过对磁浮仿真系统中多个模块的通信要求分析,可以得到模块间的数据通信具有以下特点:

1)多点对多点传输数据。如果采用面向连接的方式进行通信,则需要每个模块都各自维护到其它模块的多个连接,处理起来很不方便,并且不利于扩充模块。因此适合无连接的通信;

2)模块间的数据通信具有突发性,通信数据量不规则、不连续。比较适合采用报文转发方式传输;

3)通信目的计算机的IP地址可能改变,需要可配置;

4)模块的数量可能扩充,也就是说,在同一台计算机上运行的不同模块的通信节点可能有多个,需要可配置;

5)模块间传输数据必须保证通信的可靠性和数据的正确性;

6)某些通信要求实时性,通信异常导致陈旧数据必须清除。

3方案设计

根据第2节的影响因素分析,了解到通信方案需要解决四个问题,即通信接口问题、实时性可靠性均衡问题、IP端口可配置问题。首先,解决通信接口问题,需要将系统的数据通信工作独立出来,与原本系统的其他应用隔离开。因此,引入这样两个概念――通信层进程和应用层进程。通信层进程负责为应用层提供通信服务和其他辅助服务,如通信日志记录、通信状态监控等;应用层进程即原本系统各模块运行的应用进程,两者间数据通信靠本机进程间通信维系。基于确保实时性和大数据量的通信要求,本机进程间通信选取的方法是共享内存,然后分别为通信层和应用层提供读写共享内存的接口,即使用DLL(动态链接库)的方式分别加载到通信层程序和应用层程序中。其次,解决实时性可靠性均衡问题,从多点通信和实时性的考虑出发,决定了选取无连接且传输更高效的UDP协议。然而,UDP协议不能保证可靠性,于是想到了对UDP协议进行二次封装,形成一种兼顾通信的可靠性与实时性的新协议――RUDP协议。最后,采用通信层进程读取.ini配置文件的配置信息的方法来解决IP端口可配置问题。

3.1 本机进程间通信

本机应用层与通信层之间的进程间通信需要借助共享内存技术、动态链接库技术来实现。

共享内存技术是通过内存映射文件的方式来实现的。内存映射文件是文件内容到进程虚拟地址空间的复制。文件的内容的拷贝称为文件映像,而操作系统用来维持该拷贝的内部结构称为文件映射对象。另一个进程通过使用第一个进程的文件映射对象建立映像,可以在它自己的虚拟地址空间建立完全一样的文件映像,这样就达到了进程间共享数据的目的。

设计方案将共享内存分为两种。一种发送报文时使用,应用层进程向此共享内存内写入报文,通信层进程分配线程采用轮循或接收消息通知的方式读取共享内存中的待发送报文,并通过套接字将其发送到目的计算机的通信层进程。这种共享内存可称之为发送结点共享内存。另一种与此相反,接收报文时使用,通信层进程接收到报文后,根据报文首部判断与之对应的目的应用层,并将报文写入对应的共享内存,应用层进程再读出并解封装报文。根据报文发送目的地址与源地址,可为每个源地址与目的地址分配对应的共享内存。每一块共享内存,有一个或几个写入线程,一个读出线程与其相对应。

动态链接库(DLL)技术用来提供读、写、清空共享内存的接口。在DLL完成相应共享内存的初始化工作后,发送接收双方进程通过调用该DLL中相应的写入读取共享内存的函数访问共享内存,从而实现双方的通信。双方进程启动后,用内存映射文件的方式把一块命名共享内存映射到DLL附加的各个进程地址空间。

共享内存的实现方式设计如图1所示。

3.2 UDP协议二次封装

RUDP就是在原TCP/IP协议的传输层的UDP协议和应用层之间加入了一层为保证可靠数据传送而实现的RUDP软件模块而形成的一个五层体系结构,即在原有TCP/IP模型的应用层和传输层之间加入一个定制的通信层(RUDP层),这样就可以利用UDP协议实现一种基于消息的面向连接的可靠数据传递机制。

为了保证数据传输的可靠性,可以借鉴TCP的三次握手原理,对UDP进行二次封装,形成了RUDP传输机制。报文发送方对传输的可靠性和实时性要求通过应用层与通信层的接口DLL,以出口函数的参数形式传递,然后再将这些信息封装到原报文首部。通信层中解封装报文首部,并根据这些信息灵活地选择通信方式用以提高传输效率和保证可靠。

3.3配置文件

.ini配置文件用来灵活配置系统中某台计算机需要通信的节点个数、通信目的地址、对端接收端口和本机绑定端口。.ini的读写通过调用api函数GetPrivateProfileInt();GetPrivateProfileString()和WritePrivateProfileString()来实现。

4测试验证

根据通信方案的设计,我们已经编码实现了一套通信中间件,包含单独的通信层程序、配套动态链接库通信接口及.ini配置文件,并在100Mbps传输速率的局域网中进行了一对一、多对一、多对多的测试验证,得到测试结果如下表:

5结论

文中论述的通信方案确保了整个仿真系统可以高频度大数据量地进行通信,实现了上层工作站、中层服务器与下层管理计算机之间的数据交互要求。在保证数据传输可靠性的的前提下,尽可能的满足了数据传输的实时性。通信层完全独立于需要通信的应用层,通信接口良好,可以做到灵活配置,极大地方便了应用层的调用,为今后整个仿真系统的扩展,通信需求的增加提供了良好保证。完善后的通信方案不仅适用于本仿真系统,还可以应用于类似需求的局域网多点通信中。

参考文献

[1]施炜,李峥,秦颖编著.Windows Sockets 规范及应用-Windows网络编程接口.

[2]周伟明.多核计算与程序设计.华中科技大学出版社,2009.

[3]汪翔,袁辉编著.Visual C++实践与提高.网络编程篇.中国铁道出版社,2001.

[4]郎锐,孙方编著.Visual C++网络通信程序开发基础及实例解析.2版.北京:机械工业出版社,2006.

[5]电脑编程技巧与维护杂志社编著.Visual C++编程技巧典型案例解析网络与通信及计算机安全与维护篇.北京:中国电力出版社,2005.

[6]刘化君编著.网络编程与计算技术.北京:机械工业出版社,2009.

[7]梁庚,白焰.Windows下进程间通信方式探讨.微型电脑应用,2006,22(12).

[8]马魁涛,蔡颖,郭宝峰.Win32进程间信息共享的实现方法研究.

进程间通信范文第9篇

关键词: QNX;Windows;FLEET协议;网络通信

中图分类号:TP316 文献标识码:A 文章编号:1007-9599 (2012) 11-0000-02

一、前言

由加拿大QSSL公司推出的QNX操作系统作为应用日益广泛的嵌入式实时操作系统,建立在微内核和完全地址空间保护基础之上,其由一个体积很小的微内核和一组合作模块组成,微内核为模块组提供最基本的服务,如进程间通信、底层的网络通信、进程调度和第一级中断处理等。

QNX自带的高性能、容错性网络—FLEET Networking,通过透明的分布式处理使得所有连入网络的计算机变成一个逻辑上的超级计算机。FLEET网络处理与消息传递和进程管理原语的集成,将本地和网络进程间通信(IPC, Inter-process communication)统一起来,使得网络对IPC而言是透明的。该协议框架可以将跨接于不同网络(如Ethernet + Token)的节点直接链接起来,用户程序只需要使用msg_send即可跟网络上的任意QNX节点通信。

二、FLEET协议概述

Fleet协议是QNX自带的多台相同或不同类型的计算机进行信息交换的一套通信协议,报文结构为四项内容,分别是地址头、版本段、协议头段和数据段。地址头包含目标MAC地址(6字节)和源MAC地址(6字节),总长度为12字节;版本段为2字节,标识FLEET协议版本,如在QNX 4操作系统下使用0x8203表示FLEET协议格式;协议头段定长为22字节,包含所发送数据协议的具体内容如版本、接受者、发送者、数据包大小、发送方式等,组成了FLEET协议数据包的传输状态;数据段为不定长数据,由协议头段内的数据长度字段控制。

FLEET协议中最基本的进程间通信方式是消息,消息实际发送数据过程需要由一个Attach过程、一个Send过程和一个Reply过程实现。

图1 基于消息的进程间通信

如图1所示,进程间在进行消息传递时使用三个基本函数:Send()(发送消息)、Receive ()(接收消息)、Reply()(回答发送进程)。相应的,进程存在三个基本状态: Send阻塞、Receive阻塞和Reply阻塞。

三、网络节点

为有效的传送信息,QNX提供了网络管理器(Net)对网络硬件的使用进行管理。网络管理器不必建立在微内核映像中,能够独立于网络硬件而存在,可以根据需要随时提供或撤销网络驱动能力。由于应用程序通过消息访问所有的服务,以及网络管理器允许消息在网上透明地流动,通过对网络中的计算机进行节点安排可形成一个完整的逻辑计算机。

任何节点都可使用两个数值来标识,物理节点ID和逻辑节点ID。物理节点ID是通过硬件来识别的,在硬件生产时即以确定,是一个十分庞大的数据,人或程序处理起来很困难,且有些物理ID又有差别很大的规定;逻辑节点ID是从1开始顺序分配的自然数,其最大值为该网络中的节点总数,所有QNX进程都与逻辑节点ID打交道,物理节点ID隐蔽在QNX进程上,当需要向另一个节点传输数据时,网络管理器将把对方的物理节点ID告诉驱动程序。

四、测试方案

(一)网络配置

QNX操作系统与Windows操作系统不同,为实现网络通讯,在系统启动时,需要通过加载系统映像文件,注册网络硬件资源、配置驱动程序参数。映像文件是一个包含操作系统,可执行程序以及任何与程序有关的数据文件的文件,在对控制系统的硬件资源的操作上,把硬件资源虚拟成文件,通过虚拟设备文件统一管理硬件设备。

1.创建启动镜像

(1)cd /boot;//打开/boot文件夹

(2)make b=install.1;//编译启动镜像的配置文件install.1

(3)copy /boot/install.1 /.boot;//拷贝install.1至/.boot文件夹

2.配置节点号

(1)cd /boot/build;//打开/boot/build文件夹

(2)mv install.1 install.x;//修改文件名为install.x

(3)修改install.x中的$ /boot/sys/Proc32 –l 1为$ /boot/sys/Proc32 –l x

3.生成新的image

(1)cd /boot;//打开/boot文件夹

(2)make b=install.x;//编译新的image文件install.x

(3)cp images/install.x /.boot;//拷贝install.x至/.boot文件夹

(4)cp sysinit.1 sysinit.x;//将启动镜像文件拷贝至sysinit.x

4.修改配置文件

(1)cp Input.1 Input.26.cp ph.1 ph.x

(2)cp tcpip.1 tcpip.x

(3)修改tcpip.x的 ip地址

进程间通信范文第10篇

一、引言

随着计算机应用的不断深入和信息交流的不断增加,许多unix系统用户越来越感到,仅由一台高性能微机运行unix,带多台至几十台终端已不能满足应用的需要,因此,越来越多的系统正在向多用户网络方向发展。

unix tcp/ip网络就是解决上述矛盾的一种系统。它将多台运行unix系统的超级微机用电缆线连接起来,采用tcp/ip协议进行通信,任一微机所连接的终端可登录到网上其它任一主机上进行操作,也可以通过网络提供的功能,进行其它网络操作。

sco unix tcp/ip网络系统为用户提供了许多通信功能,它包括远程登录、文件传输、邮件发送以及其它有关网络应用、管理及控制方面的命令。这些功能均在命令级实现,即用户只需在命令提示符下键入相应的命令,即可完成相应的操作。但是,有许多应用系统对网络功能的调用是在应用程序运行过程中的,仅通过命令接口是不能完全满足应用的需要的,因此,用户必须通过网络提供的接口编制自己的网络应用程序。sco unix tcp/ip为用户提供了一组套接字接口,本文将介绍如何通过调用套接字以及tcp/ip提供的库函数编制一个文

件传输应用程序。

二、套接字接口及调用

1.套接字接口

一个用户应用系统,即一个客户进程,通常需要与一个完成其功能有的服务进程进行通信。在unix系统中完成这种进程间通信的一个方法是通过管道(pipes)来实现的,unix网络运行系统也提供一个更灵活的强有力的独立子系统以支持一个分布式环境的进程间通信,这个子系统就称作套接字(socket)接口。套接字接口构成了在单个主机内及整个网际间的编程界面和进程间通信的基础。

一个套接字是一个软件实体,它为进程间通信提供了基本的构件,它是进程间通信的端点,对互连网地址来说,下面的一对全名套接字唯一确定了通信双方的连接:

<<node.port><node.port>>

其中,node是4字节地址,port为2字节长,左边的是本地套接字,右边是远程或外部套接字。

套接字具有类型,其类型是由面向程序员的通信特性决定的,它与套接字支持的特殊协议有关。时程通常是在相同类型的套接字之间通信。目前程序员可使用下面三种类型的套接字。

·流套接字:提供双向的、可靠的、有序的且不重复的无记录边界的数据流,它是最常用的一种类型。

·数据报套接字:它支持双向数据流,但记录边界被保持,接收进程必须重新定序,消除重复并提供可靠保证,它适用于单个报文的可靠性不重要的场合。

·原始套接字:使用原始套接字,程序员能访问低层通信协议(如ip),它不是为一般用户设置的,而是为了开发新的通信协议,或是为了访问现有协议中较隐蔽功能而设置的。

2.套接字的调用

tcp/ip的系统调用主要是通过对套接字的操作来实现的,下面给出了部分常用的tcp/ip系统调用:

·scoket 创建套接字

·bind 为套接字赋一个名字

·connect 启动一个连接

·accept 接受连接

·listen 监听连接

·write/send 发送信息

·read/recv 接收信息

·close 关闭套接字

三、unix网络库例程的应用

网络库例程的主要用途是确定和建立网络地址。

在客户方与服务方进行通信前,在远程节点上确定一个服务需要进行多级映射。为便于使用,每个服务被指定一个名字,这个名字必须被翻译成网络地址,最后,该地址被用来确定一个物理位置和到服务的路径。可见,确定远程节点上的一个服务需要三级映射,这三级映射的具体实现随着网络结构不同而有所变化。

unix网络库例程是c程序语言函数调用,它提供下列映射的标准例程:

·主机名字到网络地址

·网络地址到网络号

·协议名字到协议号

·服务名字到端口号及服务器使用的适当协议

1.映射主机名字

例程gethostbynamne,gethostbyaddr,gethostent均可完成主机名字与地址映射,它们分别将主机名或节点地址映射成一个hostent结构:

struct hostent{

char * h_name;/* 正式主机名 */

char * * h_aliasea;/* 别名表 */

int h_addrtype;/* 主机的地址类型 */

int h_length;/* 地址长度*/

char * * h_addr_list; /* 地址表 */

#define h_addr h_addr_list[0]

}

2.映射网络名字

getnetbyname, getnetbynumber,getnetent是分别用于映射网络名字的例程,使用这些例程,可将网络名映射到网络号,或把网络号映射到网络名,并返回一个netent结构:

struct netent{

char * n_name;/* 正式的网络名 */

char * * n_aliasea;/* 别名表 */

int n_addrtype;/* 网络地址类型 */

unsignedlong n_net;/* 网络号 */

}

3.映射服务名字

通过指定一个服务名和一个可选的合法协议,例程getservbyname,getservbyport,get

servent映射服务名字到一个servent结构:

struct servent{

char * s_name;/* 正式的服务名 */

char * * s_aliasea;/* 别名表 */

int s_port;/* 服务驻留的端口号 */

char * s_proto; /* 所使用的协议 */

}

四、文件传输程序的编制

利用网络所提供的套接字接口和库例程,采用客户/服务器模式来编制文件传输程序。

程序流程如下:

@@t8s09300.gif;图1@@

在通信之前,要为服务分配端口地址,这个地址分配是在/etc/services文件中设置的。

服务方进程启动后,它创建套接字,指定服务名和合法协议,并在指定端口地址上监听服务请求。

客户方进程开始后,也要创建套接字,指定服务名和协议号,并启动一个与服务方的连接,连接成功后,则立刻开始数据传送,直到文件传送结束。

五、结束语

本文只是在多用户网络应用方面的一个初控,利用网络所提供的接口,我们可以在更深层次对其进行研究,开发出功能更强、更为灵活、适用的网络应用软件。 参考文献

1 蔡传俊,unix/tcp/ip/nfs网络编程与应用开发。北京:海洋出版社,1993(1)。

上一篇:光通信范文 下一篇:无线通信范文

友情链接