《UNIX网络编程 卷2:进程间通信(第2版)》——第1章 简介 1.1 概述

第1章 简介

1.1 概述

IPC是进程间通信(interprocess communication)的简称。传统上该术语描述的是运行在某个操作系统之上的不同进程间各种消息传递(message passing)的方式。本书还讲述多种形式的同步(synchronization),因为像共享内存区这样的较新式的通信需要某种形式的同步参与运作。

在Unix操作系统过去30年的演变史中,消息传递历经了如下几个发展阶段。

  • 管道(pipe,第4章)是第一个广泛使用的IPC形式,既可在程序中使用,也可从shell中使用。管道的问题在于它们只能在具有共同祖先(指父子进程关系)的进程间使用,不过该问题已随有名管道(named pipe)即FIFO(第4章)的引入而解决了。
  • System V消息队列(System V message queue,第6章)是在20世纪80年代早期加到System V内核中的。它们可用在同一主机上有亲缘关系或无亲缘关系的进程之间。尽管称呼它们时仍冠以“System V”前缀,当今多数版本的Unix却不论自己是否源自System V都支持它们。

在谈论Unix进程时,有亲缘关系(related)的说法意味着所论及的进程具有某个共同的祖先。说得更明白点,这些有亲缘关系的进程是从该祖先进程经过一次或多次fork派生来的。一个常见的例子是在某个进程调用fork两次,派生出两个子进程。我们说这两个子进程是有亲缘关系的。同样,每个子进程与其父进程也是有亲缘关系的。考虑到IPC,父进程可以在调用fork前建立某种形式的IPC(例如管道或消息队列),因为它知道随后派生的两个子进程将穿越fork继承该IPC对象。我们随图1-6详细讨论各种IPC对象的继承性。我们还得注意,从理论上说,所有Unix进程与init进程都有亲缘关系,它是在系统自举时启动所有初始化进程的祖先进程。然而从实践上说,进程亲缘关系开始于一个登录shell(称为一个会话)以及由该shell派生的所有进程。APUE的第9章详细讨论会话和进程亲缘关系。 本书将全文使用缩进的插入式注解(如此处所示)来说明实现上的细节、历史上的观点以及其他琐事。

  • Posix消息队列(Posix消息队列,第5章)是由Posix实时标准(1003.1b-1993,将在1.7节详细讨论)加入的。它们可用在同一主机上有亲缘关系和无亲缘关系的进程之间。
  • 远程过程调用(Remote Procedure Call,简称RPC,第5部分)出现在20世纪80年代中期,它是从一个系统(客户主机)上某个程序调用另一个系统(服务器主机)上某个函数的一种方法,是作为显式网络编程的一种替换方法开发的。既然客户和服务器之间通常传递一些信息(被调用函数的参数与返回值),而且RPC可用在同一主机上的客户和服务器之间,因此可认为RPC是另一种形式的消息传递。

看一看由Unix提供的各种同步形式的演变同样颇有教益。

  • 需要某种同步形式(往往是为了防止多个进程同时修改同一文件)的早期程序使用了文件系统的诡秘特性,我们将在9.8节讨论其中的一些。
  • 记录上锁(record locking,第9章)是在20世纪80年代早期加到Unix内核中的,然后在1988年由Posix.1标准化的。
  • System V信号量(System V semaphore,第11章)是在System V消息队列加入System V内核的同时(20世纪80年代早期)伴随System V共享内存区(System V shared memory)加入的。当今多数版本的Unix都支持它们。
  • Posix信号量(Posix semaphore,第10章)和Posix共享内存区(Posix shared memory,第13章)也由Posix实时标准(1003.1b-1993)加入。
  • 互斥锁(mutex)和条件变量(condition variable,见第7章)是由Posix线程标准(-1995)定义的两种同步形式。尽管往往用于线程间的同步,它们也能提供不同进程间的同步。
  • 读写锁(read-write lock,第8章)是另一种形式的同步。它们还没有被Posix标准化,不过也许不久后会被标准化。
时间: 2025-01-02 13:19:45

《UNIX网络编程 卷2:进程间通信(第2版)》——第1章 简介 1.1 概述的相关文章

《UNIX网络编程 卷1:套接字联网API(第3版)》——2.6 TCP连接的建立和终止

2.6 TCP连接的建立和终止 为帮助大家理解connect.accept和close这3个函数并使用netstat程序调试TCP应用,我们必须了解TCP连接如何建立和终止,并掌握TCP的状态转换图. 2.6.1 三路握手建立一个TCP连接时会发生下述情形. (1)服务器必须准备好接受外来的连接.这通常通过调用socket.bind和listen这3个函数来完成,我们称之为被动打开(passive open). (2)客户通过调用connect发起主动打开(active open).这导致客户T

《UNIX网络编程 卷1:套接字联网API(第3版)》——导读

**前言**本书面向的读者是那些希望自己编写的程序能使用称为套接字(socket)的API进行彼此通信的人.有些读者可能已经非常熟悉套接字了,因为这个模型几乎已经成了网络编程的同义词,但有些读者可能仍需要从头开始学习.本书想达到的目标是向大家提供网络编程指导.这些内容不仅适用于专业人士,也适用于初学者:不仅适用于维护已有代码,也适用于开发新的网络应用程序:此外,还适用于那些只是想了解一下自己系统中网络组件的工作原理的人. 书中的所有示例都是在Unix系统上测试通过的真实的.可运行的代码.但是,考

《UNIX网络编程 卷1:套接字联网API(第3版)》——2.7 TIME_WAIT状态

2.7 TIME_WAIT状态 毫无疑问,TCP中有关网络编程最不容易理解的是它的TIME_WAIT状态.在图2-4中我们看到执行主动关闭的那端经历了这个状态.该端点停留在这个状态的持续时间是最长分节生命期(maximum segment lifetime,MSL)的两倍,有时候称之为2MSL. 任何TCP实现都必须为MSL选择一个值.RFC 1122[Braden 1989]的建议值是2分钟,不过源自Berkeley的实现传统上改用30秒这个值.这意味着TIME_WAIT状态的持续时间在1分钟

《UNIX网络编程 卷1:套接字联网API(第3版)》——2.3 用户数据报协议(UDP)

2.3 用户数据报协议(UDP) UDP是一个简单的传输层协议,在RFC 768[Postel 1980]中有详细说明.应用进程往一个UDP套接字写入一个消息,该消息随后被封装(encapsulating)到一个UDP数据报,该UDP数据报进而又被封装到一个IP数据报,然后发送到目的地.UDP不保证UDP数据报会到达其最终目的地,不保证各个数据报的先后顺序跨网络后保持不变,也不保证每个数据报只到达一次. 我们使用UDP进行网络编程所遇到的问题是它缺乏可靠性.如果一个数据报到达了其最终目的地,但是

《UNIX网络编程 卷1:套接字联网API(第3版)》——1.3 协议无关性

1.3 协议无关性 图1-5中的程序是与IPv4协议相关的:我们分配并初始化一个sockaddr_in类型的结构,把该结构的协议族成员设置为AF_INET,并指定socket函数的第一个参数为AF_INET. 为了让图1-5中的程序能够在IPv6上运行,我们必须修改这段代码.图1-6所示的是一个能够在IPv6上运行的版本,其中改动之处用加粗的等宽字体突出显示. 我们只修改了程序的5行代码,得到的却是另一个与协议相关的程序:这回是与IPv6协议相关的.更好的做法是编写协议无关的程序.图11-11将

《UNIX网络编程 卷1:套接字联网API(第3版)》——2.14 小结

2.14 小结 UDP是一个简单.不可靠.无连接的协议,而TCP是一个复杂.可靠.面向连接的协议.SCTP组合了这两个协议的一些特性,并提供了TCP所不具备的额外特性.尽管绝大多数因特网应用(Web.Telnet.FTP和电子邮件)使用TCP,但这3个协议对传输层都是必要的.在22.4节中我们将阐述选用UDP替代TCP的理由.在23.12节中我们将阐述选用SCTP替代TCP的理由. TCP使用三路握手建立连接,使用四分组交换序列终止连接.当一个TCP连接被建立时,它从CLOSED状态转换到EST

《UNIX网络编程 卷1:套接字联网API(第3版)》——1.12 小结

1.12 小结 图1-5展示了一个尽管简单但却完整的TCP客户程序,它从某个指定的服务器读取当前时间和日期:而图1-9则展示了其服务器程序的一个完整版本.这两个例子引入了许多本书其他部分将要扩展的概念和术语. 我们的客户程序与IPv4协议相关,我们于是把它修改成使用IPv6,但这样做却只是给了我们另外一个协议相关的程序.我们将在第11章中开发一些可用来编写协议无关代码的函数,这在因特网开始使用IPv6后会变得非常重要. 纵贯本书,我们将使用1.4节中介绍的包裹函数来缩短代码,同时又保证测试每个函

《UNIX网络编程 卷1:套接字联网API(第3版)》——第1章 简介 1.1概述

第一部分 简介和TCP/IP 第1章 简介 1.1 概述 要编写通过计算机网络通信的程序,首先要确定这些程序相互通信所用的协议(protocol).在深入设计一个协议的细节之前,应该从高层次决断通信由哪个程序发起以及响应在何时产生.举例来说,一般认为Web服务器程序是一个长时间运行的程序(即所谓的守护程序,daemon),它只在响应来自网络的请求时才发送网络消息.协议的另一端是Web客户程序,如某种浏览器,与服务器进程的通信总是由客户进程发起.大多数网络应用就是按照划分成客户(client)和服

《UNIX网络编程 卷2:进程间通信(第2版)》——导读

**前言 **大多数重要的程序都涉及进程间通信(Interprocess Communication, IPC).这是受下述设计原则影响的自然结果:把应用程序设计为一组相互通信的小片断比将其设计为单个庞大的程序更好.从历史角度看,应用程序有如下几种构建方法. (1)用一个庞大的程序完成全部工作.程序的各部分可以实现为函数,函数之间通过参数.返回值和全局变量来交换信息. (2)使用多个程序,程序之间用某种形式的IPC进行通信.许多标准的Unix工具都是按这种风格设计的,它们使用shell管道(IP