《UNIX网络编程 卷2:进程间通信(第2版)》——2.2 IPC名字

2.2 IPC名字

在图1-4中我们指出,三种类型的Posix IPC都使用“Posix IPC名字”进行标识。mq_open、sem_open和shm_open这三个函数的第一个参数就是这样的一个名字,它可能是某个文件系统中的一个真正的路径名,也可能不是。Posix.1是这么描述Posix IPC名字的。

它必须符合已有的路径名规则(必须最多由PATH_MAX个字节构成,包括结尾的空字节)。
如果它以斜杠符开头,那么对这些函数的不同调用将访问同一个队列。如果它不以斜杠符开头,那么效果取决于实现。
名字中额外的斜杠符的解释由实现定义。
因此,为便于移植起见,Posix IPC名字必须以一个斜杠符打头,并且不能再含有任何其他斜杠符。遗憾的是这些规则还不够,仍会出现移植性问题。

Solaris 2.6要求有打头的斜杠符,但是不允许有另外的斜杠符。假设要创建的是一个消息队列,创建函数将在/tmp中创建三个以.MQ开头的文件。例如,如果给mq_open的参数为/queue. 1234,那么这三个文件分别为/tmp/.MQDqueue.1234、/tmp/.MQLqueue.1234和/tmp/. MQPqueue.1234。Digital Unix 4.0B则在文件系统中创建所指定的路径名。

当我们指定一个只有单个斜杠符(作为首字符)的名字时,移植性问题就发生了:我们必须在根目录中具有写权限。例如,/tmp.1234符合Posix规则,在Solaris下也可行,但是Digital Unix却会试图创建这个文件,这时除非我们有在根目录中的写权限,否则这样的尝试将失败。如果我们指定一个/tmp/test.1234这样的名字,那么在以该名字创建一个真正文件的所有系统上都将成功(前提是/tmp目录存在,而且我们在该目录中有写权限,对于多数Unix系统来说,这是正常情况),在Solaris下则失败。

为避免这些移植性问题,我们应该把Posix IPC名字的#define行放在一个便于修改的头文件中,这样应用程序转移到另一个系统上时,只需修改这个头文件。

这是一个标准试图变得相当通用(本例子中,实时标准试图允许消息队列、信号量和共享内存区都在现有的Unix内核中实现,而且在独立的无盘系统上也能工作),结果标准的具体实现却变得不可移植的个例之一。在Posix中,这种现象称为"造成不标准的标准方式"(a standard way of being nonstandard)。
Posix.1定义了三个宏:

S_TYPEISMQ(buf)

S_TYPEISSEM(buf)

S_TYPEISSHM(buf)

它们的单个参数是指向某个stat结构的指针,其内容由fstat、lstat或stat这三个函数填入。如果所指定的IPC对象(消息队列、信号量或共享内存区对象)是作为一种独特的文件类型实现的,而且参数所指向的stat结构访问这样的文件类型,那么这三个宏计算出一个非零值。否则,计算出的值为0。

不幸的是,这三个宏没有多大用处,因为无法保证这三种类型的IPC使用一种独特的文件类型实现。举例来说,在Solaris 2.6下,这三个宏的计算结果总是0。

测试某个文件是否为给定文件类型的所有其他宏的名字都以S_IS开头,而且它们的单个参数是某个stat结构的st_mode成员。由于上面三个新宏的参数不同于其他宏,因此它们的名字改为以S_TYPEIS开头。
px_ipc_name函数
解决上述移植性问题的另一种办法是自己定义一个名为px_ipc_name的函数,它为定位Posix IPC名字而添加上正确的前缀目录。

本书中我们给自己定义的非标准系统函数都使用这样的版式:围绕函数原型和返回值的方框是虚框。开头包含的头文件通常是我们的unpipc.h(图C-l)。

name参数中不能有任何斜杠符。例如,调用

px_ipc_name("test1")

在Solaris 2.6下返回一个指向字符串/testl的指针,在Digital Unix 4.0B下返回一个指向字符串/tmp/test1的指针。存放结果字符串的内存空间是动态分配的,并可通过调用free释放。另外,环境变量PX_IPC_NAME能够覆盖默认目录。

图2-2给出了该函数的实现。

这也许是你第一次碰到snprintf函数。许多现有代码调用的是sprintf,但是sprintf不检查目标缓冲区是否溢出,不过snprintf要求其第二个参数是目标缓冲区的大小,因此可确保缓冲区不溢出。提供能有意溢出一个程序的sprintf缓冲区的输入数据是黑客们已使用很多年的一种攻破系统的方法。

snprintf不是标准ANSI C的一部分,但这个标准的修订版C9X正在考虑。①不过,许多厂家提供的标准C函数库含有这个函数。我们在本书中使用snprintf,如果你的系统不提供这个函数,那就使用我们自己的通过调用sprintf实现的版本。

时间: 2024-11-03 09:12:25

《UNIX网络编程 卷2:进程间通信(第2版)》——2.2 IPC名字的相关文章

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

第1章 简介 1.1 概述 IPC是进程间通信(interprocess communication)的简称.传统上该术语描述的是运行在某个操作系统之上的不同进程间各种消息传递(message passing)的方式.本书还讲述多种形式的同步(synchronization),因为像共享内存区这样的较新式的通信需要某种形式的同步参与运作. 在Unix操作系统过去30年的演变史中,消息传递历经了如下几个发展阶段. 管道(pipe,第4章)是第一个广泛使用的IPC形式,既可在程序中使用,也可从she

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

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

《UNIX网络编程 卷2:进程间通信(第2版)》——1.9 小结

1.9 小结 IPC传统上是Unix中一个杂乱不堪的领域.虽然有了各种各样的解决办法,但没有一个是完美的.我们的讨论分成4个主要领域: (1)消息传递(管道.FIFO.消息队列): (2)同步(互斥锁.条件变量.读写锁.信号量): (3)共享内存区(匿名共享内存区.有名共享内存区): (4)过程调用(Solaris门.Sun RPC). 我们考虑单个进程中多个线程间的IPC以及多个进程间的IPC. 各种类型IPC的持续性可以是随进程持续的.随内核持续的或随文件系统持续的,这取决于IPC对象存在时

《UNIX网络编程 卷1:套接字联网API(第3版)》——1.10 Unix标准

1.10 Unix标准 在编写本书时,最引人注目的Unix标准化活动是由Austin公共标准修订组(The Austin Common Standards Revision Group,CSRG)主持的.他们的努力结果是涵盖1 700多个编程接口的约4 000页内容的规范[Josey 2002].这些规范既具有IEEE POSIX名字,也具有开放团体的技术标准(The Open Group's Technical Standard)名字.其结果是同一个Unix标准有多个名字来指称:ISO/IEC

《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将